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I INTRODUCTION* 

In  our  book  A Computational  Logic  [1]  we  describe  a formal  logic 
based  on  recursive  functions,  and  we  present  a large  number  of 
techniques  for  discovering  proofs  of  theorems  In  that  theory.  As  noted 
In  A Computational  Logic  we  have  Implemented  our  theorem-proving 
techniques  In  an  automatic  theorem-prover.  This  document  explains  how 
to  use  that  automatic  theorem-prover.  We  assume  that  the  reader  Is 
familiar  with  the  motivation  and  orientation  of  our  theorem-proving 
research  and  con^letely  understands  the  formal  logic  In  which  we  are 
proving  theorems.  The  reader  unfamiliar  with  these  aspects  of  our  work 
should  read  the  first  five  chapters  of  A Computational  Logic  before 
attempting  to  use  the  theorem-prover  seriously.  Throughout  the  rest  of 
this  manual  we  refer  to  Chapter  n of  A Computational  Logic  as  ACL  n.  We 
assume  the  reader  Is  familiar  with  the  DEC  TOPS-20  operating  system, 
particularly  with  the  file  naming  conventions,  (see  [2]).  We  also 
assume  the  reader  Is  familiar  with  INTERLISP  (see  [3]). 

The  theorem-prover  Is  actually  a set  of  INTERLISP  programs.  To  use 
the  theorem-prover  you  log  on  to  a computer,  enter  INTERLISP,  load  the 
appropriate  theorem-prover  files,  and  then  call  theorem-prover  programs 
to  define  new  concepts,  axlomatlze  new  types  of  objects,  and  prove 
theorems . 

A.  Teaching  the  Theorem-Prover 


While  using  our  program  you  will  spend  most  of  your  time  teaching 
the  system  about  the  concepts  you  define  and  their  relationships  to 
other  defined  concepts.  The  system  Is  taught  by  defining  functions  and 
suggesting  lemmas  for  It  to  prove  and  remember  for  future  use. 


The  development  of  our  theorem-prover  was  supported  In  part  by  the 
National  Science  Foundation  under  Grant  MCS-7681425  and  by  the  Office  of 
Naval  Research  under  Contract  N0014-75-C-0816. 


1 


'Tsn 


The  system  uses  axioms  and  previously  proved  lemmas  In  four 
distinct  ways.  The  system  does  not  decide  automatically  how  to  use  a 
given  theorem;  whenever  any  new  theorem  Is  Introduced,  you  must  specify 
how  the  lemma  Is  to  be  used  by  providing  the  system  with  a set  of 
tokens,  INTERLISP  literal  atoms,  called  "lemma  types,"  taken  from  the 
set  {REWRITE  ELIM  GENERALIZE  INDUCTION}.  REWRITE  lemmas  are  used  to 
rewrite  terms.  ELIM  lemmas  are  used  to  eliminate  certain  function 
symbols  by  re-representlng  variables  In  the  problem.  GENERALIZE  lemmas 
are  used  to  restrict  the  range  of  variables  Introduced  by 
generalizations.  INDUCTION  lemmas  are  used  to  justify  new 
Induct Ion /recurs Ion  schemes.  Note  that  by  Introducing  a lemma  with  the 
empty  list  of  lemma  types  you  cause  the  system  to  name  the  formula  and 
save  It,  but  to  store  It  so  that  It  will  be  used  In  no  way  (l.e..  It  Is 
not  used  In  future  proofs). 

The  theorem-prover  Is  very  sensitive  to  the  syntactic  form  chosen 
by  you  to  express  each  new  fact.  For  example,  a REWRITE  lemma  of  the 
form 


(IMPLIES  (AND  p q)  (EQUAL  r s)) 

Is  used  to  rewrite  (Instances  of)  r to  s provided  the  system  can  first 
establish  p and  then  q.  Note  the  asymmetry  between  hypothesis  and 
conclusion,  and  between  left-  and  right-hand  sides  of  the  conclusion. 
In  fact,  because  the  system  must  limit  the  resources  It  Is  willing  to 
spend  establishing  p and  q,  even  the  order  of  the  hypotheses  Is 
relevant.  That  Is,  the  above  REWRITE  lemma  causes  different  behavior 
than  any  of  the  following  logically  equivalent  formulas: 

(IMPLIES  (AND  p q)  (EQUAL  s r)) 

(IMPLIES  (AND  p (NOT  (EQUAL  r s)))  (NOT  q)) 

(IMPLIES  (AND  q p)  (EQUAL  r s) ) 

To  become  an  effective  user  of  the  system  you  must  understand  how 
your  commands  Influence  the  behavior  of  the  system.  It  Is  possible  to 
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Infer  the  meaning  of  the  various  lemma  types  after  enough  hands-on 
experience  with  the  system.  (It  Is  also  possible  to  Infer  the  structure 
of  a brick  wall  by  battering  It  down  with  your  head.)  We  highly 
recommend  that  the  serious  user  of  the  system  read  A Computation^ 

Logic,  paying  special  attention  to  the  heuristics  controlling  lemmas  and 
definitions,  and  the  carefully  explained  examples.  For  a brief 
description  of  the  syntactic  requirements  on  formulas  of  the  various 
lemma  types,  see  the  discussions  under  each  lemma  type  name  In  the 
REFERENCE  GUIDE  (Section  III  of  this  User's  Manual). 

B.  Events.  Dependencies,  and  Commands 

Every  definition  and  theorem  known  to  the  theorem-prover  has  a 
name.  The  act  of  Introducing  a new  definition  or  theorem  to  the  system 
Is  called  an  "event."  Some  events,  such  as  definitions,  are  naturally 
associated  with  a name  (e.g. , the  name  of  the  function  defined);  others, 
such  as  theorems,  are  given  names  by  the  user.  See  the  subsection 
Syntax  below  for  the  syntactic  restrictions  on  names. 

The  basic  theorem-prover  commands  are  those  that  create  new  events: 
the  addition  of  a new  axiom,  the  Introduction  of  a new  type  of  object, 
the  definition  of  a new  function,  and  the  proof  and  storage  of  a new 
theorem.  The  INTERLISP  functions  that  create  new  events  are  ADD. AXIOM, 
ADD. SHELL,  BOOT. STRAP,  DCL,  DEFN,  PROVE.LEMMA,  and  MOVE. LEMMA.  Some 
events  Introduce  several  new  axioms,  each  of  which  Is  assigned  a name  by 
the  system.  These  subevents  are  considered  "satellites"  of  the  "main 
event."  For  example,  the  Introduction  of  a new  shell  type  (e.g.  CONS) 

Is  one  event  that  gives  rise  to  many  subevents  (e.g.,  axioms  about  CONS, 
CAR,  CDR,  and  LISTP).  Every  theorem  or  function  name  In  the  system  Is 
either  a main  event  or  a satellite  of  a main  event. 

Events  are  related  to  each  other  by  logical  dependencies.  For 
example,  the  admission  of  a certain  formula  as  a theorem  depends  upon 
all  of  the  functions  and  lemmas  used  In  the  proof  of  the  theorem. 
Similarly,  the  admission  of  a new  recursive  function  definition  depends 
not  only  upon  all  of  the  previously  Introduced  concepts  used  In  the 


definition,  but  also  upon  the  functions  and  lemmas  used  to  prove  that 
the  proposed  "definition"  truly  defines  a function. 

Thus,  the  theorem-p rover 's  "state"  or  "knowledge  base"  is  actually 
a noncircular,  directed  graph  of  events.  The  theorem-prover's 
performance  is  largely  determined  by  Its  knowledge  base.  For  example, 
there  are  many  theorems  It  can  prove  only  after  It  has  proved  certain 
key  lemmas.  It  Is  possible  to  dump  the  system's  knowledge  base  to  a 
"library  file"  to  save  the  system's  state  from  one  session  to  the  next. 

In  addition  to  the  basic  commands,  the  system  provides  many 
commands  for  operating  on  the  graph  of  events:  obtaining  the  events 

that  depend  upon  a given  event,  undoing  an  event,  or  editing  and  re- 
executlng  the  command  that  created  an  event.  Several  functions  delete 
events  from  the  graph.  The  graph  Is  always  kept  consistent  In  the  sense 
that  when  an  event  Is  deleted  all  the  events  that  are  (directly  or 
Indirectly)  dependent  upon  the  event  being  deleted  are  also  deleted. 

Thus,  If  after  proving  several  theorems  you  find  that  one  of  your 
earliest  defined  concepts  was  inconveniently  or  inappropriately  defined, 
you  can  "undo"  that  definition  and  lose  only  those  results  whose  meaning 
or  logical  validity  may  depend  upon  that  definition. 

C . Error  Handling 

If  you  try  to  execute  an  Inappropriate  command  (e.g.,  assign  the 
same  name  to  two  different  events,  or  attempt  to  define  a function  In 
terms  of  unknown  concepts)  self-explanatory  error  messages  will  be 
printed.  The  system  checks  for  over  100  errors  and  has  a sophisticated 
error  handling  mechanism  designed  to  keep  the  theorem-proving  machine  In  j 

a consistent  state.  For  example,  when  a new  command  Is  processed,  all 
possible  errors  are  checked  before  the  first  change  Is  made  to  the  data 
base,  since  an  abortion  midway  through  the  update  would  leave  the 
machine  In  an  unacceptable  state. 

i 

Errors  are  grouped  Into  three  classes,  warnings,  soft  errors,  and  , 

fatal  errors  (distinguished  by  the  headers  WARNING,  ERROR,  and  FATAL 

ERROR  In  the  message  printed).  Warnings  arise  when  the  system  has  ' 
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detected  something  unusual  but  not  logically  Incorrect.  For  example, 
the  system  prints  a warning  message  If  you  define  a function  but  do  not 
refer  to  one^of  the  formal  parameters  In  the  body  of  the  function. 

After  printing  a warning  message,  the  system  continues  normal  execution. 

Soft  errors  are  true  errors  In  the  sense  that  the  system  cannot 
continue  until  the  error  Is  repaired,  but  they  are  the  type  of  errors 
that  can  be  repaired  by  editing  a formula  or  changing  a name.  When  such 
an  error  occurs  the  system  prints  an  explanatory  error  message  and  then 
calls  the  INTERLISP  editor  on  the  offending  command  If  possible.  If  you 
exl;  the  editor  normally  (with  OK)  the  command  Is  re-executed.  If  you 
exit  abnormally  (e.g.,  with  STOP  or  CTRL-D),  the  theorem-proving  machine 
Is  left  In  the  same  clean  state  It  was  In  before  the  offending  command 
was  encountered. 
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Fatal  errors  occur  when  system  resources  are  exhausted  or  when 
Internal  checks  Indicate  the  presence  of  Inconsistency  In  the  data  base 
or  bugs  In  the  theorem-prover  Itself.  It  Is  usually  not  possible  to 
proceed  past  a fatal  error.  Such  errors  should  be  reported  to  Boyer  and 

Moore.  I 

• j 

Despite  our  precautions,  there  Is  a relatively  simple  way  for  you 
to  get  the  system  Into  an  Illegal  state:  abort  with  control  B,  D,  or  E 
while  the  system  Is  In  the  process  of  updating  Its  data  base.  For 
example.  If  you  Interrupt  the  definition  process  while  It  Is  Iteratively 
computing  the  output  type  of  the  newly  defined  function,  the  systi'-m  may 
appear  to  believe  In  an  inaccurate  characterization  of  the  function's 
type.  Such  an  Illegal  state  will  more  usually  manifest  Itself  by 
ultimately  causing  a fatal  error  or  even  an  INTERLISP  error  (which  Is  to 
our  system  what  a "trap  at  location  n"  Is  to  INTERLISP).  It  Is  often 
not  possible  to  recover  from  such  an  interruption,  even  Immediately 
after  the  fact.  For  example  If  you  abort  a definition  after  the  system 

has  begun  to  store  facts  about  It,  you  cannot  properly  undo  the  aborted  | 

definition  because  Insufficient  undo  Information  was  stored.  Since  you 
cannot  In  general  tell  whether  the  system  Is  In  the  process  of  updating 

the  data  base,  the  moral  Is:  i 
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NEVER  ABORT  ANY  COMMAND  THAT  MIGHT  BE  UPDATING  THE  DATA  BASE. 

If  you  realize  you  typed  a command  incorrectly,  wait  until  the  system 
detects  an  error  In  It  (after  which  you  can  abort  from  within  the 
editor)  or  until  the  system  accepts  It  (after  which  you  can  undo  It). 

Eventually,  we  will  invest  the  effort  necessary  to  protect  the 
critical  sections  of  our  code.  At  the  moment  we  assume  the  users  to  be 
sophisticated  and  friendly  — and  we  don't  put  our  stamp  of  approval  on 
any  proof  except  one  constructed  from  an  uninterrupted  sequence  of 
BOOT. STRAP,  ADD. AXIOM,  ADD. SHELL,  DCL,  DEFN,  PROVE. LEMMA  and  MOVE. LEMMA 
commands. 

D . Output 

The  theorem-p rover  prints  an  English  description  of  what  It  is 
doing  as  it  proceeds.  The  values  of  the  variables  PROVE. FILE  and  TTY: 
determine  where  Its  output  Is  printed. 

The  system  directs  all  of  its  output.  Including  error  messages,  to 
PROVE. FILE.  Thus,  if  you  are  not  interested  in  seeing  the  output  from  a 
sequence  of  commands,  you  can  set  PROVE. FILE  to  the  name  of  an  open  file 
and  look  at  the  output  later.  This  is  particularly  useful  when  you  want 
to  collect  some  proofs  that  you  are  confident  the  system  can  perform 
(e.g.,  because  It  has  done  them  before). 

If  PROVE. FILE  Is  different  from  TTY:,  the  system  also  prints  its 
error  messages  to  TTY:.  Thus,  if  you  wanted  to  write  your  proofs  to  a 
disk  file  but  would  like  to  see  any  messages  that  arise,  set  PROVE. FILE 
to  the  disk  and  TTY:  to  T.  if  you  would  like  even  error  messages  to  be 
directed  to  a disk  file  (l.e.,  you  want  the  theorem-prover  to  print 
nothing  to  the  terminal),  set  TTY:  to  a disk  file  too.  By  setting  TTY: 
and  PROVE. FILE  to  different  disk  files  you  will  get  a complete 
transcript  of  the  system's  output  (possibly  interleaved  with  error 
messages)  In  PROVE. FILE,  and  a separate  file  containing  Just  the  error 
messages  In  TTY:.  This  makes  It  easy  to  determine  whether  any  messages 
occurred.  None  should. 
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Rigging  the  system  to  run  without  printing  to  the  terminal  Is 
useful  when  you  are  running  the  theorem-p rover  in  a detached  Job.  For 
the  details  of  how  to  run  while  detached,  see  REDO.  UNDOr^E.  EVE  NTS  and 
PROVEALL  (in  the  REFERENCE  GUIDE). 

E.  Syntax 

As  you  are  no  doubt  aware,  all  formulas  in  our  logic  are  written  in 
a LISP-like  prefix  notation.  Indeed,  they  are  just  INTERLISP  S- 
expresslons.  We  have  no  parser.  We  find  this  convenient  since  at  the 
command  level  In  our  system  you  are  typing  to  INTERLISP. 

Certain  rules  must  be  obeyed  in  writing  down  names  and  S- 
expresslons  In  our  language.  All  names  (e.g.,  function  names,  variable 
names,  event  names)  must  be  INTERLISP  literal  atoms.  You  may  only  form 
names  using  the  characters  in  the  list  LEGAL. NAME. CHARS.  Currently  that 
list  contains  upper  case  A through  Z,  0 through  9,  /,  \,  >,  <,  =, 

@,  +,  *,  &,  %,  $,  #,  Finally,  every  name  must  start  with  one  of 

the  26  alphabetic  characters  and  must  not  end  with  a period,  and  must  be 
more  than  one  character  long. 

T and  F are  acceptable  abbreviations  for  the  terms  (TRUE)  and 
(FALSE).  You  may  not  use  T and  F as  variables.  0 is  an  abbreviation 
for  the  bottom  object  of  type  NUMBERP:  the  constant  term  (ZERO).  1 is 
an  abbreviation  for  (ADDl  0),  2 for  (ADDl  1),  etc. 

As  noted  in  ACL  III,  LITATOMs  in  our  theory  are  either  the  bottom- 
most LITATOM  (which  is  returned  by  the  constant  function  NIL  and  written 
(NIL))  or  are  constructed  by  the  unary  function  PACK.  Thus,  (PACK  x)  is 
a LITATOM.  NIL  is  an  acceptable  abbreviation  for  (NIL).  (Because 
INTERLISP  does  not  allow  NIL  to  have  a property  list,  NIL  is  not  used 
internally  as  a function  symbol;  instead  we  use  NIHIL).  Recall  that  in 
our  logic  NIL  is  different  from  F,  the  false  truth  value. 

In  ACL  III,  we  present  a convention  for  naming  LITATOMs  using 
quotation  marks.  Since  ACL  was  written,  we  have  abandoned  that 
convention  and  we  have  adopted  another  convention,  using  the  syntax 
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(QUOTE  ...)  familiar  to  LISP  programmers.  That  Is,  In  our  current 
theorem-prover  we  write  (QUOTE  atm)  Instead  of  "atm".  (QUOTE  atm), 
where  atm  is  an  INTERLISP  literal  atom  is  an  acceptable  abbreviation  for 
(PACK  n),  for  some  n;  the  n's  corresponding  to  different  atm's  are 
different.  The  system  arbitrarily  decides  the  correspondence. 

(Currently,  the  correspondence  is  determlnced  by  the  order  of  first 
use.)  Thus  you  should  never  use  PACK  directly.  (QUOTE  NIL)  is  NIL. 

(QUOTE  T)  is  a LITATOM,  and  is  not  T,  the  true  truth  value.  (QUOTE  x), 
where  x is  a nonnegative  INTERLISP  Integer,  is  the  same  as  x. 

The  reason  that  we  abandoned  the  quotation  mark  convention  for 
denoting  literal  atoms  used  in  ACL  was  to  obtain  the  effect  that  the 
QUOTE  in  LISP  has  on  "arguments"  other  than  literal  atoms.  (QUOTE  x), 
where  x is  an  INTERLISP  list  structure  (car  . cdr).  is  taken  to  mean  the 
term  (CONS  (QUOTE  car)  (QUOTE  cdr)).  Thus,  (QUOTE  (0  1))  is  taken  to 
mean: 

(CONS  0 (CONS  1 NIL)) 

which  is 

(CONS  (ZERO) 

(CONS  (ADD!  (ZERO))  (NIL))). 

Function  symbols  beginning  with  C,  ending  with  R,  containing  only 
A's  and  D's  in  between,  and  differing  from  CR,  are  abbreviations  for 
compositions  of  CAR's  and  CDR's.  For  example,  (CADDR  X)  means  (CAR  (CDR 
, (CDR  X))). 

Before  you  mention  a function  symbol  in  an  expression  it  must  be 
known  to  the  system.  Thus,  if  you  misspell  a function  name  (and  the 
resulting  symbol  is  not  in  fact  a known  function)  an  error  will  occur. 

If  you  wish  to  use  a function  symbol  without  defining  or  introducing  it 
via  the  shell  principle,  you  must  first  use  the  program  DCL  to  declare 
. the  name  to  the  system.  (See  DCL  in  the  REFERENCE  GUIDE.) 

It  is  not  permitted  to  apply  a function  to  too  few  arguments.  For 
• example,  giving  the  theorem-prover  an  S-expresslon  involving  (CONS  X) 

will  cause  an  error.  Note  that  in  INTERLISP,  (CONS  X)  is  an 

abbreviation  for  (CONS  X NIL);  but  we  do  not  support  that  convention  in 

' \ 
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; 
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our  theory*  It  Is  also  not  permitted  to  give  a function  of  0 or  1 

arguments  too  many  arguments.  For  example,  (CAR  A B)  will  cause  an 

error.  However  we  have  a rather  unusual  handling  of  the  case  In  which 

you  provide  a function  of  2 or  more  arguments  with  too  many  arguments. 

(PLUS  X Y Z U)  nmans: 

(PLUS  Z 

(PLUS  Y 

(PLUS  Z U))) 

For  functions  of  2 arguments  this  default  right-association  In  the 
second  argument  position  Is  quite  convenient.  For  example,  (AND  P Q R) 
Is  just  what  you  would  want,  and  (CONS  A B C D NIL)  Is  the  same  as 
INTERLISP's  (LIST  A B C D). 

For  functions  of  more  than  2 arguments,  e.g. , BIGPLUS  which  takes 
4,  the  second  argument  Is  right-associated  and  the  trailing  arguments 
are  duplicated,  e.g., 

(BIGPLUS  X Y U V BASE  CARRY) 

means 

(BIGPLUS  X 

(BIGPLUS  Y 

(BIGPLUS  U V BASE  CARRY) 

BASE 

C/RRY) 


BASE 

CARRY) 


II  GETTING  INTO  AND  OUT  OF  THE  THEOREM- PROVEN 
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A.  Getting  Into  the  Theorem-Prover 
1.  ^ the  KL-IO 

On  SRI's  KL-IO,  the  th e o re m-p rover  resides  on  directory 
<MOORE>.  To  start  the  theorem-p rover  you  should  first  Inform  the 
operating  system  that  you  will  be  requiring  files  found  on  directory 
<MOORE>  by  typing: 

^DEFINE  DSK:  DSK:,<MOORE> 
to  the  TOPS-20  EXEC. 

Then  start  up  a fresh  INTERLISP  and  execute: 

(LOAD  '•qiOORE>CODE.IHlT) 


If  the  SYSOUT  file  <MOORE>THM.EXE  exists,  you  can  get  the 
effect  of  starting  a fresh  INTERLISP  and  loading  CODE.INIT  by  typing; 

®IUN  <MOORE>THM.EXE 

to  the  TOPS-20  EXEC.  When  this  SYSOUT  file  exists  It  Is  much  faster  to 
enter  the  system  this  way  than  by  the  sequence  of  LOADs. 

To  complete  the  Initial  loading  of  the  system,  you  must  call 
the  function  INIT.  As  explained  In  the  REFERENCE  GUIDE  section  of  this 
document,  INIT  performs  several  functions,  one  of  which  Is  to  Initialize 
the  theorem-prover's  knowledge  base.  If  you  wish  to  Initialize  the 
theorem-prover's  knowledge  base  to  the  most  primitive  one  available 
(described  In  ACL  III),  you  should  execute: 
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(INIT  T) 

If  you  wish  to  Initialize  the  theorem-prover's  knowledge  base  to  some 
previously  saved  "library  file"  (see  the  user  command  MAKE. LIB),  you 
should  execute: 

(INIT  (QUOTE  file)) 

where  file  is  the  name  of  the  library  file  in  question.  The  standard 
library  we  use  is  <MOORE>PROVEALL.LIB  and  contains  several  hundred 
definitions  and  previously  proved  theorems  (including  most  of  those 
described  in  A Computat ional  Logic) . You  are  welcome  to  use  this  file 
for  early  experimentation.  However,  if  you  intend  to  apply  the  theorem- 
prover  to  some  particular  and  difficult  problem  you  may  prefer 
eventually  to  construct  your  own  library  from  scratch. 

Having  called  INIT  with  some  non-NIL  argument  you  are  ready  to 
go:  your  core  image  contains  the  latest  "blessed"  version  of  the 
theorem-p rover  and  a specified  knowledge  base.  You  may  then  use  the 
commands  described  in  the  REFERENCE  GUIDE. 

2.  On  Other  TOPS-20  Systems 

To  move  the  theorem-p rover  to  another  TOPS-20  system,  create  a 
directory  <MOORE>  and  copy  to  it  the  files  named  in  the  file  [SRI- 
KL] 'WOORE>CODE. FILES.  The  files  should  be  copied  to  files  with  the  same 
version  numbers  as  the  source  files.  The  files  may  be  obtained  from 
SRI-KL  over  the  ARPANET. 

If  you  cannot  obtain  the  files  via  the  ARPANET,  we  will 
provide  a magnetic  tape  copy  of  the  files  for  a nominal  charge. 

B . Saving  the  Knowledge  Base 

When  your  session  is  over  you  may  want  to  save  the  theorem-prover's 
knowledge  base.  There  are  two  ways  to  do  it.  One  is  to  use  MAKE .LIB  to 
produce  a library  file  suitable  for  giving  to  INIT  when  you  next  enter 
the  theorem-p rover.  The  other  is  to  use  EVENTS. SINCE  to  obtain  a list 
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of  all  the  axioms,  definitions,  and  theorems  you  have  added  to  the 
system  during  this  session,  to  save  those  formulas  on  some  file,  and  to 
reprocess  those  formulas  with  REDO. UNDONE. EVENTS  as  the  first  official 
act  of  your  next  session. 

The  first  method  may  consume  lots  of  disk  space  because  the  entire 
knowledge  base  (l.e.,  the  old  one  plus  the  extension  performed  during 
the  current  session)  will  have  to  be  saved;  but  It  only  requires  a few 
CPU  seconds.  The  second  method  of  saving  your  work  requires  only  the 
disk  space  needed  to  write  down  the  formulas  you  typed  In;  but  It  may 
require  a good  deal  of  time  to  reprocess  those  formulas  upon  your  next 
entry.  For  example,  to  save  the  entire  knowledge  base  after  proving  all 
the  theorems  In  our  standard  library  requires  122  file  pages  and  about 
30  CPU  seconds  (total)  coming  and  going.  Saving  the  formulas  themselves 
only  requires  22  pages  but  It  takes  about  2 CPU  hours  to  prove  all  those 
formulas  again.  We  generally  use  the  second  method  only  when  our 
Initial  knowledge  base  Is  already  very  large  and  the  extension  performed 
during  the  current  session  Is  no  more  than  10  or  20  simple  definitions 
and  lemmas. 

The  usual  INTERLISP  method  of  saving  state,  using  SYSOUT  to  produce 
a runnable  EXE  file  with  your  current  core  Image  In  It,  should  be  used 
with  caution.  See  the  discussion  under  NOTE. FILE  In  the  REFERENCE 
GUIDE. 
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Ill  REFERENCE  GUIDE 


Unless  otherwise  noted,  all  of  our  INTERLISP  functions  are  "lambda- 
spread"  — i.e.,  they  take  a fixed  number  of  arguments  that  are 
evaluated  by  INTERLISP  before  the  function  is  executed.  Since  most  user 
commands  are  typed  directly  to  the  INTERLISP  top-level  executive,  we  use 
the  "EVALQUOTE"  syntax  to  Illustrate  the  commands. 

Each  command  that  creates  an  event  takes  as  its  last  argument  a 
comment.  The  comment  argument  to  a command  must  be  either  NIL  or  a list 
whose  first  element  is  the  literal  atom  * (asterisk).  The  comment  is 
stored  with  the  event.  It  is  useful  to  comment  your  function 
definitions  and  lemmas  for  the  same  reason  it  is  useful  to  comment  your 
programs.  In  the  description  of  the  event-creating  commands,  we  omit 
the  comment  argument  for  typographic  reasons. 

This  REFERENCE  GUIDE  lists,  in  alphabetical  order,  all  of  the  user- 
level  functions,  variables,  and  tokens  in  our  system. 

A.  ADD .AXIOM(name  lemma. types  term) 

ADD. AXIOM  adds  a new  axiom  to  the  system.  The  statement  of  the 
axiom  is  term,  the  name  of  the  axiom  is  name,  and  the  axiom  is  used  in 
each  of  the  ways  listed  in  lemma. types.  Each  element  of  lemma. types 
must  be  a lemma  type,  and  the  syntactic  form  of  term  must  permit  its  use 
in  each  of  the  ways  specified.  The  restrictions  on  the  members  of 
lemma. types  are  given  under  the  individual  type  names. 

Here  is  a sample  axiom  about  an  undefined  function  APPLY  (see  DCL 
for  how  to  introduce  new,  undefined  function  symbols): 

_ADD .AXIOM(APPLY.PLUS 

(REWRITE) 

(EQUAL  (APPLY  (QUOTE  PLUS)  X Y) 

(PLUS  X Y)) 

(*  This  axiom,  named  APPLY. PLUS  and 
used  as  a rewrite  rule  only,  says 
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that  for  all  X and  Y,  the  result 

of  APPLYlng  the  LITATOM 

PLUS  to  X and  Y is  their  Peano  sum*)) 

We  provide  a mechanism  for  adding  axioms  with  extreme  reluctance* 

It  is  very  easy  and  painless  to  beg  the  question  with  a mechanical 
theorem-prover  by  asking  it  to  assume  too  much. 

B • ADD. SHELL (shell. name  btm.oblect  recognizer  destructor .tuples) 

ADD. SHELL  axlomatizes  a new  shell  class.  In  our  theory,  shells 
play  the  role  that  "data  types"  play  in  programming  language.  Shells 
are  typed  ordered  n-tuples,  possibly  with  type  restrictions  on  the 
components.  A shell  class  is  characterized  by  a "constructor"  function 
that  takes  n arguments  and  returns  an  n-tuple  of  a unique  type;  a 
"recognizer"  that  returns  T or  F according  to  whether  its  argument  is  an 
element  of  that  type;  n "destructor"  (or  "accessor")  functions  that  dig 
out  the  components  of  an  n-tuple  of  that  type;  and,  optionally,  a 
"bottom  object"  (l.e.,  an  object  of  that  type  but  not  an  n-tuple).  It 
is  possible  to  specify  restrictions  on  the  types  of  objects  occupying 
each  slot  of  the  n-tuple.  It  is  also  possible  to  specify  "default 
values"  to  be  used  when  an  object  of  the  wrong  type  is  supplied  for  a 
component  or  when  an  accessor  is  applied  to  an  object  of  the  wrong  type. 

The  constructor  name  for  the  type  axlomatlzed  by  ADD. SHELL  is 
shell. name;  the  recognizer  name  is  recognizer;  and  the  destructors  are 
given  in  the  list  des tructor .tuples,  which  is  a list  of  n elements,  each 
of  the  form  (ac  tr  dv).  The  ac's  are  the  destructor  function  names,  the 
tr's  are  the  type  restrictions  on  each  component  in  the  n-tuple,  and  the 
dv's  are  the  corresponding  default  values.  If  btm.oblect  is  NIL,  no 
default  object  is  supplied  with  the  type;  otherwise,  btm.oblect  must  be 
a list  of  the  form  (b),  where  b is  the  name  of  the  constant  function  for 
constructing  the  bottom  object.  The  restrictions  on  shell. name. 
recognizer,  the  ac's,  tr's,  dv's,  and  btm.oblect  are  given  in  ACL  III. 

The  effect  of: 


Is  the  same  as: 


• • • 


(acn  trn  dvn))) 


r 

( (acl  trl  dvl) 

Add  the  shell  const  of  n arguments 

with  (optionally,  bottom  object  (b),) 

recognizer  r, 

accessors  acl,  •••,  acn, 

type  restrictions  trl,  ...,  tm,  and 

default  values  dvl dvn. 

as  described  In  ACL  III. 

Recall  that  the  most  primitive  version  of  the  system's  knowledge 
base  Includes  the  axioms  for  the  nonnegative  Integers,  LlTATOMs , and 
CONSes.  These  axioms  are  added  by  ADD. SHELL  commands  built  Into  the 
"boot  strap"  that  occurs  when  INIT  Is  called.  The  ADD. SHELL  commands 
used  are: 

_ADD. SHELL (ADD 1 (ZERO)  NUMBER?  ( (SUBl  (NUMBER?  XI)  (ZERO)))) 

_ADD. SHELL (?ACK  (NIHIL)  LITATOM  ( (UN?ACK  T (ZERO)))) 

_ADD. SHELL (CONS  NIL  LIST?  ((CAR  T (NIHIL)) 

(CDR  T (NIHIL)))) 

(We  use  (NIHIL)  Instead  of  (NIL)  because  It  Is  not  possible  to  alter  the 
property  list  of  the  literal  atom  NIL. ) 

C.  BOOT.STRA?() 

ACL  III  describes  the  most  primitive  theory  with  which  our  system 
will  operate.  The  theory  Includes  the  functions  symbols  TRUE,  FALSE,  IF 
and  EQUAL;  the  shells  ADDl,  ?ACK,  and  CONS  (l.e.,  the  axioms  and 
functions  for  Feano  arithmetic,  LlTATOMs,  and  CONSes);  the  standard 
measure  function  COUNT;  and  the  defined  functions  LESS?,  ZERO?,  FIX,  and 
PLUS.  The  command  BOOT. STRAP  Initializes  the  system's  data  base  to  the 
theory  described  In  ACL  III.  All  of  the  axioms  and  definitions  added 
are  made  dependent  upon  the  BOOT. STRAP  event,  which  has  the  event  name 
GROUND. ZERO.  Thus  every  subsequent  event  will  be  dependent  upon 
GROUND. ZERO.  One  method  of  obtaining  a list  of  all  of  the  events  In  a 
data  base  Is  to  call  DEPENDENT. EVENTS  on  GROUND. ZERO.  Similarly,  one 
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method  of  completely  erasing  the  system's  data  base  Is  to  call  UNDO. NAME 
on  GROUND. ZERO.  Before  BOOT. STRAP  begins  to  add  the  Initial  axioms  It 
calls  UNDO. NAME  on  GROUND. ZERO  to  erase  the  existing  data  base  (If  any). 

D.  CHRONOLOGY 

The  value  of  the  variable  CHRONOLOGY  Is  a list  of  the  names  of  the 
events  In  the  current  data  base.  In  reverse  chronological  order.  Thus, 
the  first  element  of  CHRONOLOGY  Is  the  name  of  the  most  recent  event, 
and  the  last  element  Is  name  of  the  oldest  event,  GROUND. ZERO.  After 
loading  a library,  you  can  print  CHRONOLOGY  to  learn  the  names  of  the 
events  In  It. 

E.  DCLCname  args) 

DCL  declares  name  to  be  an  undefined  function  of  n arguments,  where 
n Is  the  length  of  args . args  must  be  a list  of  distinct  variable 
names.  An  undefined  function,  once  DCLed,  can  be  constrained  by  axioms, 
but  can  never  be  defined.  For  example,  to  extend  the  syntax  by  adding 
APPLY  as  an  undefined  function  of  three  arguments,  one  would  make  the 
following  declaration: 

JDCL (APPLY  (FN  X Y)) 

F.  DEFN(name  args  body) 

DEFN  defines  a function  named  name,  with  formal  argument  names  as 
listed  In  args . and  with  body  body.  Args  must  be  a list  of  distinct 
variable  names,  and  body  must  be  a term.  The  system  atteupts  to 
establish  that  the  restrictions  on  the  definitional  principle  of  ACL  III 
are  met  before  admitting  the  new  function.  The  most  severe  restriction 
Is  that  there  be  a well-founded  relation  such  that  some  measure  of  args 
gets  smaller  in  every  recursive  call  of  name  in  body.  The  system  uses 
INDUCTION  lemmas  to  guide  Its  search  for  a suitable  measure  and 
relation,  and  uses  REWRITE  lemmas  to  try  to  prove  that  the  tests  In  the 
function  body  governing  each  recursive  call  Imply  the  hypotheses  in  the 
INDUCTION  lemmas  used  to  justify  each  call.  See  ACL  III  for  the  details 
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of  the  definitional  principle,  and  ACL  XIV  for  the  details  of  the  search 
for  measures  and  well-founded  relations. 

Together  with  some  trivial  syntactic  checks,  the  existence  of  a 
measure  and  well-founded  relation  Justifying  a definitional  equation  Is 
sufficient  to  ensure  that  the  equation  of  (name  . args ) with  body  Indeed 
defines  a function  and  may  be  added  to  the  theory  without  loss  of 
soundness.  In  addition,  these  measures  and  relations  are  used  to  Invent 
Induction  arguments  for  conjectures  Involving  name.  If  the  system  Is 
unable  to  establish  the  existence  of  a measure  and  well-founded  function 
it  will  'print  a warning  message  explaining  that  it  has  assumed  that  such 
a measure  and  well-founded  relation  exist  and  that  the  soundness  of  the 
resulting  theory  rests  entirely  with  the  user. 

It  Is  to  your  advantage  to  teach  the  system  enough  about  measures 
and  relations  to  allow  it  to  find  Justifications  of  all  of  your 
functions.  This  teaching  Is  accomplished  by  defining  measures  as 
functions  and  having  the  system  prove  appropriate  INDUCTION  and  REWRITE 
lemmas.  The  system  Is  much  more  flexible  In  Inventing  good  Inductions 
when  It  Is  working  with  measures  and  relations  It  "understands"  than 
when  It  has  only  assumed  their  existence. 

Here  Is  a sample  definition. 

_DEFN (APPEND 

(X  Y) 

(IF  (LISTP  X) 

(CONS  (CAR  X)  (APPEND  (CDR  X)  Y))  , 

Y) 

(*  APPEND  concatenates  two  lists.  It  Is 
a well-defined  function  because  the 
size  of  X,  as  measured  by  the  function 
COUNT,  gets  smaller  according  to  LESSP 
In  the  recursive  call.)) 

Note  the  difference  between  the  way  DEFN  takes  Its  arguments  and  the  way 
INTERLISP's  DEFINEQ  takes  Its.  DEFINEQ  takes  a list,  each  element  of 
which  Is  a triple  of  the  form  (name  args  body).  DEFN  takes  Just  the 
components  of  one  such  triple. 

After  processing  the  definition,  the  system  prints  out  an 
explanation  of  why  the  definition  has  been  accepted  (l.e.,  the  measures 
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and  well-founded  relations  justifying  It).  In  addition  the  system 
attempts  to  determine  the  types  (l.e.,  shell  classes)  of  output  returned 
by  the  function  and  prints  out  this  Information  In  the  form  of  an 
"observed"  lemma  that  has  also  been  stored  as  a REWRITE  rule.  The 
Information  printed  by  DEFN  Is  directed  to  the  file  named  by  the  value 
of  the  variable  PROVE. FILE. 

G.  DEPENDENT . EVENTS ( name ) 

DEPENDENT. EVENTS  takes  an  event  name  (l.e.,  a function  name,  axiom 
name,  or  lemma  name)  and  returns  the  list  of  events  reachable  from  It  In 
the  dependency  graph.  The  list  of  events  returned  by  DEPENDENT. EVENTS 
Is  a list  of  INTERLISP  forms.  The  CAR  of  each  form  Is  the  INTERLISP 
function  that  created  the  event  name  (e.g.,  DEFN  or  PROVE. L0IMA)  and  the 
CDR  Is  a list  of  arguments  for  that  command. 

For  example.  If  you  Initialize  the  data  base  to  our  current 
PROVEALL.LIB  file,  the  prettyprlnted  value  of: 

DEPENDENT . EVENTS (L ESSP . LENGTH ) 


({PROVE. LEMMA  LESSP. LENGTH 
(INDUCTION) 

(IMPLIES  (LISTP  L) 

(LESSP  (LENGTH  (DELETE  (MAXIMUM  L) 

L)) 

(LENGTH  L) ))) 

(DEFN  DSORT 

(L) 

(IF  (NLISTP  L) 

NIL 

(CONS  (MAXIMUM  L) 

(DSORT  (DELETE  (MAXIMUM  L)  L))))) 

(PROVE. LEMMA  DSORT. S0RT2 
(REWRITE) 

(EQUAL  (DSORT  X)  (S0RT2  X)))) 


The  definition  of  DSORT  depends  upon  LESSP. LENGTH  and  In  turn,  the 
statement  and  proof  of  DSORT. S0RT2  depends  upon  the  definition  of  DSORT. 
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Since  all  events  can  be  reached  from  GROUND. ZERO,  you  will  get  a 
total  picture  of  the  state  of  the  theorem-p rover's  "acquired"  knowledge 
by  prettyprinting  the  value  of  DEPENDENT. EVENTS(GROUND. ZERO) . Looking 
.'t  the  dependents  of  GROUND. ZERO  Is  one  way  to  begin  Investigating  the 
kind  of  requests  that  we  type  in  and  which  functions  you  can  use  In  your 
functions. 

H.  EDITCCname) 

With  EDITC  you  can  edit  the  comment  of  the  event  name  and  not  Incur 
the  undoing  (and  redoing)  that  EDITEV  entails. 

I.  EDITEV (name) 

EDITEV  allows  you  to  edit  the  event  name.  If  name  is  not  an  event 
name,  EDITEV  prints  an  appropriate  message  and  exits.  Otherwise,  EDITEV 
obtains  the  list  of  all  events  dependent  upon  name  (using 
DEPENDENT. EVENTS),  copies  it,  and  then  calls  the  INTERLISP  editor  on  the 
entire  list  of  dependencies  with  the  first  event  — the  one  named  name 
— as  the  editor's  "current  expression."  You  may  edit  that  event  or  any 
of  the  ones  dependent  upon  It  (It  Is  often  the  case  that  when  you  change 
the  definition  of  a function,  for  example,  you  also  wish  to  change  the 
"calls"  of  that  function  elsewhere).  If  you  exit  the  editor  abnormally 
(e.g.,  with  STOP  or  CTRL-D),  even  after  making  some  tentative  changes, 
no  part  of  the  theorem-prover's  state  Is  changed.  However,  If  you  exit 
with  OK,  the  system  checks  to  see  whether  the  edited  list  of  events  is 
different  from  the  original.  If  not,  no  part  of  the  state  is  changed. 

If  the  list  of  events  Is  different,  then  event  name  Is  undone  (and 
consequently  so  are  all  the  events  dependent  upon  it),  and  each  of  the 
events  in  the  result  of  your  edit  are  re-executed  with 
REDO .UNDONE . EVENTS . 

EDITEV  is  the  only  safe  way  for  you  to  change  a definition  or  lemma 
already  added  to  the  system.  In  particular,  after  a definition  or  lemma 
has  been  processed  and  "built  into"  the  system,  trying  to  edit  it  by 
destructively  editing  property  lists  or  other  parts  of  the  actual 
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representation  of  the  theorem-prover's  state  will  almost  certainly  leave 
the  system  in  an  unreliable  state. 


I 
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J.  EDITV(name) 

EDITV  is  the  standard  Interlisp  function  for  editing  variables.  We 
have  redefined  it  so  that  it  behaves  differently  on  variables  used  in 
the  implementation  of  the  theorem-p rover.  However,  EDITV  behaves 
normally  on  any  variable  not  used  in  the  Implementation  of  the  theorem- 
prover,  with  the  exception  that  the  message  "Should  you  declare  it?" 
will  be  printed  at  the  conclusion  of  the  edit. 

K.  ELIM 

ELIM  is  one  of  the  "lemma  types"  specifying  how  a lemma  can  be 
used.  Roughly  speaking,  an  ELIM  lemma  is  used  to  replace  some  variable 
in  the  conjecture  by  a new  term,  so  as  to  allow  certain  rewrites  to 
remove  certain  function  symbols. 

An  ELIM  lemma  must  have  the  form  (IMPLIES  hyp  (EQUAL  Ihs  var)), 
where  (1)  var  is  a variable,  (2)  there  is  at  least  one  proper  subterm  of 
Ihs  of  the  form  (d  vl  ...  vn),  where  d is  a function  symbol  and  the  vl 
are  distinct  variables  and  are  the  only  variables  in  the  lemma,  and  (3) 
var  occurs  in  Ihs  only  in  such  (d  vl  ...  vn)  terms.  See  ACL  X for  a 
detailed  description  of  how  ELIM  lemmas  are  used. 

L.  EVENTS .S INCE ( event ) 

EVENTS. SINCE  returns  a list,  in  chronological  order,  of  all  the 
events  that  have  occurred  since  the  event  named  event  occurred.  Each 
event  on  the  list  is  a form  whose  CAR  is  the  name  of  the  INTERLISP 
function  that  created  the  event  and  whose  CDR  is  the  list  of  arguments 
to  that  function  (l.e.,  the  events  are  in  the  same  form  as  returned  by 
DEPENDENT. EVENTS ) . The  list  Includes,  as  its  first  element,  the  event 
named  event. 


A typical  use  of  EVENTS. SINCE  Is  to  ascertain  what  you  have 
accomplished  during  a session  (l.e.»  what  you  have  done  and  not 
subsequently  undone).  It  Is  up  to  you  to  determine  the  name  of  the 
first  event  of  the  session.  It  may  be  of  use  to  know  that  the  value  of 
the  variable  CHRONOLOGY  Is  a list  of  all  event  names.  In  reverse 
chronological  order  (l.e.,  the  first  element  of  CHRONOLOGY  Is  the  name 
of  the  last  event  created,  and  the  last  element  Is  GROUND. ZERO) . 

One  method  of  saving  the  system's  logical  state  Is  to  save  the 
events  since  you  last  did  an  INIT  or  NOTE. FILE,  and  to  bring  the  system 
up  next  time  by  Initializing  to  the  same  old  data  base  and  then  using 
REDO. UNDONE. EVENTS  to  re-execute  the  events  saved. 

M.  EVENT.FORM(x) 

If  jc  Is  an  event  name,  EVENT. FORM  returns  the  INTERLISP  S- 
expresslon  representing  the  event  that  created  It  (e.g.,  DEFN  CONSed 
onto  the  list  of  arguments).  If  3C  Is  a satellite,  EVENT. FORM  returns 
the  S-expresslon  for  Its  main  event.  Otherwise,  EVENT. FORM  returns  NIL. 

N.  FAILED. THMS 

Roughly  speakings  FAILED. THMS  Is  a list  of  all  the  conjectures  that 
the  system  has  failed  to  prove  In  the  current  session.  FAILED. THMS  Is 
maintained  as  follows.  When  you  start  up  the  system  It  Is  Initialized 
to  NIL.  Every  time  PROVE  Is  entered  It  adds  the  conjecture  to  be  proved 
to  the  list  of  conjectures  In  FAILED. THMS  (unless  the  conjecture  Is 
already  In  FAILED. THMS).  When  PROVE  terminates  normally  and  has  proved 
the  conjecture.  It  removes  It  from  FAILED. THMS.  Thus,  If  midway  through 
a proof  you  abort  with  CTRL-E,  the  conjecture  PROVE  was  called  on  will 
still  be  on  FAILED. THMS. 

FAILED. THMS  Is  not  part  of  the  knowledge  base.  Thus,  If  you  start 
up  a fresh  copy  of  the  system  and  Initialize  the  knowledge  base  to  some 
previously  saved  library  file,  FAILED. THMS  Is  not  restored  to  what  It 
was  when  the  library  file  was  created.  The  purpose  of  FAILED. THMS  Is  to 
help  you  remember  theorems  you  were  trying  to  prove  (before  you  got 
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distracted  by  trying  to  prove  the  necessary  lemmas),  and  to  save  you  the 
trouble  of  having  to  type  those  theorems  back  in  again. 

O.  FORMULA . OF ( name ) 

This  function  returns  the  S-expresslon  of  the  formula  named  name  if 
name  was  created  by  ADD.AXICM,  PROVE .LEMMA,  or  MOVE .LEMMA,  and  NIL 
otherwise.  FORMULA. OF  cannot  find  a formula  for  a satellite.  Thus,  if 
you  ask  for  the  FORMULA. OF  a lemma  name  created  by  ADD. SHELL,  the  result 
will  be  NIL,  since  the  axioms  created  during  ADD. SHELL  are  mere 
satellites  of  the  ADD. SHELL  event. 

P.  GENERALIZE 

GENERALIZE  is  one  of  the  "lemma  types"  specifying  how  a lemma  can 
be  used.  Roughly  speaking,  a GENERALIZE  lemma  mentioning  an  Instance  of 
the  term  t is  used  when  the  theorem-p rover  decides  to  generalize  a 
conjecture  containing  t by  replacing  it  with  a new  variable  v.  The 
lemma  is  used  to  restrict  v.  There  are  no  constraints  on  the  form  of 
GENERALIZE  lemmas.  See  ACL  XII  for  a detailed  description  of  how  such 
lemmas  are  used. 

Q.  GROUND. ZERO 

The  name  of  the  event  created  by  BOOT. STRAP  is  GROUND. ZERO.  All  of 
the  axioms,  definitions,  and  shells  added  by  BOOT. STRAP  are  made 
dependent  upon  GROUND. ZERO.  Consequently,  every  event  in  any  data  base 
can  be  reached  from  GROUND. ZERO. 

R.  INDUCTION 

INDUCTION  is  one  of  the  "lemma  types"  specifying  how  a lemma  can  be 

used.  Roughly  speaking,  INDUCTION  lemmas  inform  the  system  that  a given 

measure  decreases  under  the  well-founded  function  LESSP.  An  induction 

lemma  must  be  of  the  form: 

(IMPLIES  hyp 

(LESSP  (m  tl  ...  tn) 

(m  xl  ...  xn) ) ) 


^ I where  the  xl  are  distinct  variables,  all  the  variables  In  hyp  occur  In 

I I the  conclusion,  and  m Is  a function  symbol, 

‘ . The  theorem-p rover  makes  a special  exception  to  the  above  rule  for 

I • a lemma  of  the  form  (IMPLIES  hyp  (LESSP  tl  xl))  when  tl  Is  a term  that 

i ‘j  always  returns  a number.  In  this  case.  It  treats  the  lemma  as  though  It 

i li 

! j!  were: 

I ' (IMPLIES  hyp 

[ ! (LESSP  (COUNT  tl)  (COUNT  xl))) 

I If  hyp  Is  a conjunction  of  terms,  and  one  of  the  terms  Is  of  the  fonn 

I (NOT  (EQUAL  (m  tl  ...  tn)  (m  xl  ...  xn))),  the  lemma  Informs  the 

I system  that  (ml  tl  ...  tn)  Is  less  than  or  equal  to  (m  xl  ...  xn) 

\ under  the  hypotheses  In  hyp,  except  for  the  (NOT  (EQUAL  — ))  term.  Such 

! a hypothesis  Is  the  only  way  to  so  Inform  the  system  (l.e.,  the  system 

, does  not  recognize  a conclusion  of  the  form  (LESSEQP  & &)  or  (OR  (LESSP 

I & &)  (EQUAL  & &))). 

For  a detailed  discussion  of  how  INDUCTION  lemmas  are  used  read  ACL 
■ ' XIV  and  XV. 


S.  INIT(f lie) 

INIT  performs  the  last  step  In  the  process  of  bringing  up  the 

theorem-prover.  INIT  first  loads  some  "patch  files"  that  correct  bugs 

In  or  add  new  features  to  the  system  contained  In  the  main  files.  If 

file  Is  T,  INIT  then  loads  a block  compiled  version  of  the  simplifier 

and  calls  BOOT. STRAP  to  Initialize  the  system's  data  base  to  the  formal 

theory  described  In  ACL  III.  If  file  Is  not  T and  not  NIL,  It  Is 

assumed  to  be  the  name  of  a library  file  (produced  by  MAKE .LIB).  In 

this  case,  INIT  loads  the  block  compiled  simplifier  and  then  calls 

NOTE. FILE  on  file  to  Initialize  the  data  base  to  that  contained  In  file. 

? 

The  option  of  calling  INIT  with  file  set  to  NIL  Is  not  useful  to 

the  average  user.  The  resulting  system  contains  the  patch  files  but 

neither  the  block  compiled  simplifier  nor  a data  base.  Because  of  the 

lack  of  a data  base  none  of  the  theorem-prover  functions  can  be  called 

without  causing  errors  (e.g. , all  function  symbols  are  unknown).  We  use 
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the  NIL  option  for  development  purposes  (e>g.,  if  all  we  want  to  do  is 
edit  theorem-prover  programs,  it  not  necessary  to  have  a data  base 
loaded), 

T.  LEGAL. NAME. CHARS 

The  list  of  characters  permitted  in  event,  function  and  variable 
names  is  kept  in  the  variable  LEGAL. NAME. CHARS.  The  character  set  is 
restricted  for  two  reasons.  First,  it  is  convenient  for  the  theorem- 
prover  to  know  that  no  user  variable  has  certain  characters  in  it,  so 
that  it  can  use  such  "illegal"  variables  for  internal  purposes.  Second, 
PUBLISH  can  only  distinguish  English  commentary  from  references  to  event 
names  if  event  names  are  somehow  restricted. 

You  should  not  change  the  setting  of  LEGAL. NAME. CHARS,  as  that  will 
not  suffice  to  Inform  the  theorem-prover  that  its  Internal  names  must  be 
changed.  You  may  inspect  the  value  of  the  list  to  see  what  characters 
names  may  have. 

U.  LEMMAS (f ns) 

The  argument,  fns.  is  assumed  to  be  a list  of  function  symbols 
(e.g.,  TAUTOLOGY?,  GCD,  MEMBER).  LEMMAS  returns,  as  a list,  the  names 
of  all  lemmas  that  mention  all  of  the  names  in  fns . LEMMAS  is  useful 
when  you  know  you  proved  a lemma  about  some  function  symbol  but  cannot 
remember  its  name.  For  example,  if  you  recalled  that  there  was  some 
lemma  involving  both  MEMBER  and  STRPOS  and  you  wanted  to  know  all  such 
lemmas  you  could  execute: 

_LEMMAS ( (MEMBER  STRPOS)) 

Under  the  current  PROVEALL.LIB  data  base  the  result  would  be: 

(DELTAl. LEMMA  DELTAl .LESSP. IFF. MEMBER  STRPOS. LIST. APPEND) 


V.  LEMMA  TYPES 


j The  lemma  types  are  REWRITE,  ELIM,  GENERALIZE,  and  INDUCTION. 

j • 

i • W.  LIB. FILE 

LIB. FILE  is  a variable  whose  value  Is  the  name  of  the  current 
library  file,  if  any.  See  the  discussion  under  NOTE. FILE. 

X.  LIB. PROPS 

LIB. PROPS  is  a list  of  the  property  list  keys  that  the  theorem- 
prover  uses.  Property  lists  are  where  almost  all  the  information 
associated  with  events  is  stored.  (However,  see  NOTE. FILE  for  ln^ortant 
information  about  our  management  of  property  lists.)  The  remaining 
information  is  stored  on  the  variables  named  in  LIB. VARS. 
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Y.  MAKE.LIB(flle) 

MAKE. LIB  creates  a new  file,  named  file.  The  file  contains  the 
theorem-prover's  entire  current  knowledge  base.  Calling  NOTE. FILE  on 
the  created  file  will  make  the  system's  knowledge  base  exactly  what  it 
was  when  file  was  created  with  MAKE. LIB.  For  example,  if  you  began  your 
session  with  the  state  contained  in  the  file  TP. DATA. I,  then  defined 
some  functions  and  proved  some  lemmas,  and  then  called: 

_M AKE . L I B (T P . DATA) 

the  system  would  create  a new  version  of  TP. DATA,  containing  all  of  the 
data  in  TP. DATA. 1 plus  your  new  functions  and  lemmas.  In  particular, 
unless  you  undo  some  of  the  events  in  TP. DATA. 1,  the  new  file  will  be  at 
least  as  large  as  the  data  base  you  started  with. 

Library  files  (as  these  data  base  files  are  called)  are  text  files. 
By  listing  such  a file  on  the  line  printer  and  inspecting  it  you  can  get 
a good  idea  of  what  information  the  system  extracts  from  each  logical 
event  and  how  it  is  represented  internally. 

See  the  discussion  under  NOTE. FILE  for  Important  Implementation 
information  about  library  files. 
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MOVE.LEMMA(n^^^e  lemma. types  oldname) 


It  is  sometimes  convenient  (Indeed,  necessary)  to  cause  the  system 
to  "forget"  a lemma  or  to  use  It  In  a way  different  from  the  ways 
specified  when  It  was  created.  However,  the  logical  nature  of  events 
prevents  us  from  being  able  to  change  the  way  a lemma  Is  stored  after 
the  fact.  JTOVE.LQIMA  Is  a way  of  achieving  the  desired  effect  by  the 
following  slightly  devious  means.  The  first  two  arguments  to  MOVE. LEMMA 
are  Identical  to  the  first  two  arguments  of  PROVE .LEMMA,  namely  the  name 
of  an  event  to  be  created  and  a list  of  lemma  types.  The  third 
argument,  oldname.  Is  the  name  of  an  existing  axiom  or  lemma  Introduced 
by  ADD. AXIOM,  PROVE.LEMMA,  or  MOVE .LEMMA.  MOVE .LEMMA  disables  oldname 
(l.e.,  prevents  the  lemma  named  from  being  used  In  any  way  whatsoever) 
and  then  adds  the  formula  associated  with  oldname  as  a new  lemma,  with 
event  name  name,  to  be  used  In  the  ways  specified  by  lemma. types . The 
new  event  Is  made  dependent  upon  the  old,  just  as  though  the  old  had 
been  (the  only  lemma)  used  in  the  proof  of  the  new. 

Thus,  if  LEMMAl  was  stored  as  a REWRITE  lemma  and  you  now  wish  it 
were  also  a GENERALIZE  lemma,  you  could  execute: 

_MOVE. LEMMA (LEMMA2  (REWRITE  GENERALIZE)  LEMMAl 

(*  This  creates  a new  event,  named  LEMMA2, 
that  has  exactly  the  same  formula  as 
LEMMAl,  and  Is  stored  as  both  a REWRITE 
lemma  and  a GENERALIZE  lemma. 

In  addition,  LEMMAl  Is  disabled.)) 

The  new  event  is  named  LEMMA2  and  adds  three  facts  to  the  world:  LEMMAl 
cannot  be  used,  the  formula  named  LEMMA2  (which  happens  to  be  the  same 
as  the  formula  named  LEMMAl)  may  be  used  as  a rewrite  rule,  and  the 
formula  named  LEMMA2  may  be  used  as  a generalize  lemma.  Future  proofs 
might  employ  LEMMA2  in  either  of  the  two  ways  specified.  If  you  later 
used  UNDO. NAME  to  undo  the  MOVE. LEMMA  (l.e.,  the  event  named  LEMMA2)  the 
system  would  undo  those  events  that  depended  upon  LEMMA2  and  erase  the 
three  facts  added  to  the  world  by  the  MOVE. LEMMA.  Note  in  particular 
that  undoing  LEMMA2  permits  LEMMAl  to  be  used  again. 

If  you  wished  to  prevent  the  system  from  using  the  fact  expressed 
by  LEMMAl  at  all,  you  could  execute: 

_M0VE.LEMMA(LEMMA2  NIL  LEMMAl) 


which  disables  LEMMAl,  creates  the  event  LEMMA2  with  the  same  formula  as 
LEMMAl,  and  stores  It  so  that  It  can  not  be  used*  Subsequently  undoing 
LEMMA2  will  restore  the  potency  of  LEMMAl. 

Note  the  difference  between  using  MOVE. LEMMA  to  disable  LEMMAl  and 
using  UNDO. NAME  to  undo  LEMMAl.  The  first  does  not  disable  results 
derived  from  LEMMAl  while  the  second  eliminates  LEMMAl  and  all  of  its 
dependents.  Also,  the  first  Is  an  event  and  can  be  undone,  while  the 
second  Is  not  an  event  and  leaves  no  trace  of  LEMMAl. 

AA.  NO.BUILT.IN.ARITH.FLG 

After  we  finished  writing  A Computational  Logic  we  implemented  a 
linear  arithmetic  subroutine  in  the  simplifier.  The  theorem-prover  on 
<MOORE>  Includes  this  simplifier.  The  subroutine  knows  about  0,  ADDl, 
SUBl,  NUMBER?,  LESSP,  and  PLUS  and  can  determine  for  some  sets  of  linear 
Inequalities  that  they  are  unsatlsf lable . The  implementation  Includes 
heuristics  which  instantiate  and  apply  REWRITE  type  lemmas,  both  as 
rewrite  rules  and  as  additional  inequalities.  See  the  discussion  of  the 
REWRITE  lemma  type  for  more  details  on  which  rewrite  rules  are  used. 

The  linear  arithmetic  subroutine  enables  the  system  is  able  to 
prove  many  facts  of  linear  Integer  arithmetic  very  quickly.  However,  it 
is  sometimes  Instructive  to  see  how  those  facts  would  be  approached  by 
the  version  of  the  system  that  knows  nothing  of  arithmetic  beyond 
Peano's  axioms.  Therefore  we  provided  a switch  with  which  the 
subroutine  could  be  turned  on  and  off. 

If  NO.BUILT.IN.ARITH.FLG  is  set  to  NIL  then  the  linear  arithmetic 
subroutine  is  turned  on.  enabled.  REWRITE  lemmas  of  a special  form 
(described  under  REWRITE)  are  stored  in  a special  way  and  not  as  rewrite 
rules.  If  the  flag  is  set  to  T,  then  the  subroutine  is  turned  off. 

While  the  flag  is  set  to  T,  REWRITE  lemmas  of  the  special  form  are 
stored  as  rewrite  rules.  Initially  NO.BUILT.IN.ARITH.FLG  is  NIL. 
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AB.  NOTE. FILE (file) 

This  function  initializes  the  system's  knowledge  base  to  that 
contained  in  the  file  file.  It  is  assumed  that  file  was  produced  by 
MAKE. LIB. 

There  must  not  be  a knowledge  base  at  the  time  of  the  NOTE. FILE; 
attempting  to  bring  in  a second  knowledge  base  will  cause  an  error  (and 
your  state  will  be  not  in  fact  have  been  changed).  This  restriction  is 
enforced  because  we  have  no  means  of  ensuring  that  the  facts  in  one 
knowledge  base  are  consistent  with  those  in  another.  Thus,  if  you  have 
been  proving  theorems  and  wish  to  restore  the  system's  state  to  some 
previously  saved  one,  you  must  first  erase  your  current  knowledge  base 
by  calling  UNDO. NAME  on  GROUND. ZERO,  upon  which  depend  the  initial 
axioms  (and,  hence,  all  subsequent  definitions  and  proofs).  After 
undoing  GROUND. ZERO  the  system  will  be  in  its  virgin  state  (e.g.,  it 
will  not  even  recognize  the  function  symbol  IF)  and  you  can  then  call 
NOTE. FILE  on  the  saved  library  file.  (Alternatively,  and  usually  more 
efficiently,  you  may  start  up  an  entirely  fresh  version  of  the  theorem- 
prover  and  INIT  the  desired  file.) 

Most  of  the  system's  data  is  stored  on  the  property  lists  of 
function  symbols  and  theorem  names.  Effectively,  MAKE. LIB  writes  all 
these  properties  out,  and  NOTE. FILE  loads  them  in.  However,  to  save 
space,  NOTE. FILE  only  stores  the  name  of  the  file  to  be  "loaded"  in  the 
variable  LIB. FILE  and  arranges  for  its  properties  to  be  loaded 
Incrementally,  one  property  at  a time,  as  they  are  called  for.  This  is 
done  by  hanging  a note  on  each  atom  Involved,  pointing  to  the  byte 
address  (implicitly  in  LIB. FILE)  at  which  the  properties  for  that  atom 
are  stored.  Instead  of  accessing  properties  with  GETPROP  and  PUTPROP  we 
access  them  with  our  own  special  functions  GETl  and  PUTl. 

Thus,  NOTE. FILE  does  not  take  very  much  time  to  "notice"  a library 
file.  Furthermore,  noticing  a file  does  not  take  much  space,  even  for  a 
very  large  library.  But  the  main  advantages  of  this  implementation 
accrue  from  the  fact  that  properties  are  never  brought  in  unless  they 
are  asked  for,  and  in  a typical  session,  many  properties  never  are.  For 
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exan^le,  unless  you  undo  an  event,  the  Information  Indicating  what  must 
be  undone  Is  never  In  main  memory.  Undo  and  dependency  Information 
represents  about  40Z  of  the  data  In  a library  file.  Another  savings 
comes  from  the  observation  that  lemmas  about  one  clique  of  function 
symbols  may  never  be  referenced  In  proofs  about  another  clique.  For 
example.  If  you  are  proving  theorems  about  list  processing  functions, 
you  may  never  bring  in  the  function  symbols  and  lemmas  about  prime 
numbers , 

The  theorem-prover  actually  uses  MAKE, LIB  and  NOTE, FILE  together  to 
swap  out  Its  data  base  when  the  total  number  of  CONSes  tied  up  In 
property  lists  exceeds  a certain  number  (the  value  of  MAX, PROP, CNT, 
Initially  set  to  20000),  When  this  happens,  the  system  calls  MAKE, LIB 
to  create  a new  library  file  with  the  name  SWAPPEDLIB,  Then  It  erases 
all  properties  and  calls  NOTE, FILE  on  the  SWAPPEDLIB  file.  The  result 
is  that  no  property  Is  In  memory  and  the  list  space  can  be  reclaimed, 
GETl  will  swap  in  the  properties  one  by  one  as  they  are  called  for.  For 
example,  when  we  drive  the  theorem-prover  through  the  proofs  of  the 
several  hundred  theorems  In  Its  standard  data  base.  It  runs  out  of 
property  list  space  twice  and  twice  swaps  the  data  base  out  and 
continues.  Of  course,  after  each  swap  subsequent  processing  brings  back 
in  some  of  the  old  properties,  but  not  all  of  them  are  brought  back  In 
because  the  system  is  also  progressing  through  cliques  of  function 
symbols  and  Is  not  undoing  events  or  Inspecting  dependencies  of  old 
ones. 

To  keep  your  directory  from  being  cluttered  with  SWAPPEDLIB  files, 
swapping  destroys  the  old  SWAPPEDLIB,  The  rule  used  Is  that  If  a swap 
occurs  while  the  current  LIB, FILE  Is  a SWAPPEDLIB  file,  the  old  file  Is 
killed  by  smashing  Its  length  to  0 and  deleting  It,  (This  frees  the 
disk  space  without  doing  a TOPS-20  EXPUNGE,)  Because  of  this  behavior 
you  should  never  create  a library  file  with  main  name  SWAPPEDLIB,  nor 
should  you  ever  Intend  to  keep  a SWAPPEDLIB  file  from  one  day  to  the 
next.  If  for  some  reason  you  want  to  keep  a SWAPPEDLIB  file  you  should 
rename  It, 


Because  the  theo rem-p rove r may  need  to  create  a swapped  library  to 
avoid  running  out  of  list  space,  you  should  not  run  the  theorem-prover 
unless  you  have  several  hundred  free  pages  of  disk  space.  If  you  will 
not  tolerate  the  creation  of  such  a file,  set  the  variable  MAX. PROP. CNT 
to  300000. 

The  use  of  swapped  library  files  makes  it  inconvenient  to  use  the 
INTERLISP  SYSOUT  command  to  save  the  state  of  the  theorem-prover.  If 
you  insist  on  using  SYSOUT,  here  is  the  recommended  procedure.  First 
see  what  the  value  of  LIB .FILE  is.  If  it  is  NOBIND  (which  means  there 
is  no  library  file  and  all  properties  are  in  memory)  or  anything  other 
than  the  name  of  a SUAPPEDLI6  file,  you  are  safe.  You  can  do  the 
SYSOUT,  creating  an  EXE  file  that  can  be  restarted  with  the  TOPS-20  RUN 
command.  However,  at  the  time  you  run  the  EXE  file,  make  sure  that  the 
file  named  by  a non-NOBIND  LIB. FILE  is  on  the  connected  directory  under 
exactly  the  same  name  (thus  you  must  save  both  the  EXE  file  and  the  file 
named  by  LIB. FILE).*  The  LIB. FILE  will  be  opened  automatically  the  first 
time  it  is  referenced.  If,  when  you  want  to  call  SYSOUT,  LIB .FILE  is  a 
SWAPPEDLIB  file  you  should  first  rename  it.  Failure  to  do  so  will  mean 
that  future  sessions  based  on  that  EXE  file  may  kill  the  swapped  library 
upon  which  the  EXE  file  was  based  and  you  will  not  be  able  to  use  the 
EXE  file  a second  time.  To  rename  LIB. FILE  proceed  as  follows:  (CLOSEF 
LIB. FILE)  to  close  the  file,  CTRL-C  up  to  the  monitor;  use  the  TOPS-20 
RENAME  command  to  rename  the  file  just  closed  to  some  new  name,  newlib; 
CONTINUE  back  into  INTERLISP,  and  (SETQ  LIB. FILE  (INPUT  (INFILE 
'newlib)))  to  reset  the  value  of  LIB. FILE  to  the  new  name.  Then  you  are 
free  to  make  and  use  the  SYSOUT  just  as  though  you  were  not  running  with 
a swapped  library. 


In  connection  with  this  problem,  note  that  if  at  the  time  of  your 
SYSOUT  LIB. FILE  is  set  to  <MOORE>PROVEALL.LIB , you  are  implicitly 
relying  on  us  to  keep  that  particular  PROVEALL.LIB  file  around. 

However,  we  cannot  guarantee  to  do  so,  since  we  generally  provide  a new 
library  file  every  time  we  release  a new  version  of  the  system.  Thus, 
you  should  take  responsibility  for  saving  that  file  by  copying  it  to 
your  directory  and  renaming  the  LIB. FILE  before  the  SYSOUT  as  described 
below. 


AC.  PPE(x) 
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PPE  is  an  NLAMBDA-nospread  INTERLISP  function  (it  takes  an 
indefinite  number  of  arguments  that  are  not  evaluated  before  the 
function  is  entered).  The  arguments  should  be  names  of  events  or 
satellites  (i.e.,  function,  axiom,  or  lemma  names).  For  each  member  of 
X,  PPE  prettyprints  (to  the  primary  output  file)  the  corresponding 
event.  Here  is  an  example: 

_PPE (TIMES  TIMES. ZERO  PLUS  POP. PUSH  FOO) 

(DEFN  TIMES 
(I  J) 

(IF  (ZEROP  I) 

0 

(PLUS  J (TIMES  (SUBl  I)  J)))) 

(PROVE. LEMMA  TIMES. ZERO 
(REWRITE) 

(EQUAL  (TIMES  X 0)  0)) 

(A****  PLUS  is  a satellite  of 
(BOOT. STRAP) ) 

(A****  POP. PUSH  is  a satellite  of 
(ADD. SHELL  PUSH  NIL  STACKP 

((TOP  T 0)  (POP  T 0)  ))) 

(*****  FOO  is  neither  an  event  nor  satellite) 

No  mechanical  method  is  provided  for  obtaining  the  formula 
corresponding  to  a satellite  name.  For  example,  as  noted  in  the  example 
above,  POP. PUSH  is  a satellite  of  a certain  ADD. SHELL  command.  In  fact, 
POP. PUSH  is  the  system  generated  name  of  the  rewrite  rule  (EQUAL  (POP 
(PUSH  X Y) ) Y).  The  only  way  a user  can  determine  the  formula 
corresponding  to  a satellite  is  to  consult  A Computational  Logic. 
Appendix  C of  the  book  gives,  in  schematic  form,  the  axioms  added  by 
ADD. SHELL  and  their  names.  All  of  the  names  Introduced  during  the 
initial  boot  strap  (e.g.,  IF,  TRUE,  ADDl,  CONS,  PLUS)  are  considered 
satellites  of  GROUND. ZERO.  ACL  III  describes  the  formal  theory 
"created"  by  the  boot  strap. 
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AD.  PPR(fnaa  pprflle) 

PPR  Is  the  connnon  entry  to  our  prettyprlnt  routine.  It  takes  a 
term  in  our  theory  and  a file  open  for  output,  and  prettyprints  the  term 
to  the  file.  PPR  returns  NIL. 

There  are  three  advantages  to  using  PPR  instead  of  the  INTERLISP 
prettyprinter.  First,  PPR  knows  how  to  introduce  the  abbreviations 
permitted  by  our  theory.  For  example, 

(APPLY  (PACK  (ADDl  (ZERO))) 

(ADDl  (ADDl  (ZERO))) 

(CAR  (CDR  X))) 

is  printed  as: 

(APPLY  (QUOTE  PUSHV)  2 (CADR  X)) 

(in  the  current  PROVEALL.LIB  data  base  where  (QUOTE  PUSHV)  happens  to  be 
assigned  (PACK  1)).  Second,  PPR  produces  more  readable  output  and 
usually  puts  the  formula  on  fewer  lines  than  the  INTERLISP  prettyprinter 
because  PPR  confutes,  rather  that  guesses  at,  the  exact  amount  of  space 
a subexpression  will  require.  Third,  PPR  is  faster  than  the  INTERLISP 
prettyprinter,  especially  on  large  expressions. 

AE.  PPRIND(f mla  lef tmargln  rparcnt  ppr. macro. 1st  pprf lie) 

PPRIND  is  the  most  flexible  entry  into  our  prettyprlnt  routine,  it 
prettyprints  fmla.  in  the  columns  between  lef tmargin  and  (LINELENGTH)  of 
file  pprf lie.  PPRIND  considers  the  leftmost  character  position  on  a 
line  to  be  column  0.  Thus  column  lef  tmargln  has  lef tmargin  characters 
to  the  left  of  it.  PPRIND  assumes  that  when  called  the  "print  head"  (or 
file  pointer)  is  positioned  at  the  point  at  which  you  want  the  first 
character  to  come  out.  Thus,  if  you  want  the  formula  printed  starting 
in  column  5,  you  should  print  5 spaces  and  then  call  PPRIND  with 
lef tmargln  set  to  5.  Recognizing  the  occasional  need  to  output 
characters  immediately  after  the  last  character  printed,  PPRIND  will 
guarantee  to  leave  at  least  rparcnt  spaces  between  the  last  character 
printed  and  (LINELENGTH).  Thus,  if  you  wanted  to  prettyprlnt  the 
formula,  but  wanted  to  make  sure  there  was  at  least  enough  space  on  the 
last  line  to  print  a comma,  you  would  call  PPRIND  with  rparcnt  set  to  1. 
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jf  The  list  ppr .macro. 1st  provides  a facility  for  "macro  expanding"  forms 

I ' before  they  are  printed*  ppr. macro. 1st  Is  assumed  to  be  a list  of 

K 

J ordered  pairs  of  the  form  (hd  . fn).  When  PPRIND  encounters  a form  to 

be  printed  that  starts  with  an  atom  In  the  hd  position  of  such  a pair, 
j It  applies  fn  to  the  form  and  prettyprlnts  the  result  Instead  of  the 

■ original  form.  It  Is  with  ppr. macro. Ist  that  PPR  Introduces  Its 

^ abbreviations  (l.e. , a "ppr  macro"  transforms  (ADDl  (ADDl  (ZERO)))  to  2, 

I but  leaves  (ADDl  (ADDl  X))  alone). 

I 

! 

AF.  PROVE(thm) 

PROVE  attempts  to  prove  the  conjecture  thm.  using  all  the  theorem- 
proving techniques  at  the  system's  disposal.  PROVE  prints  an  English 
description  of  the  proof  attempt  In  real-time,  so  you  can  monitor  the 
progress  of  the  attenpt.  The  proof  description  Is  printed  to  the  file 
named  by  the  value  of  the  variable  PROVE. FILE.  Initially,  PROVE. FILE  Is 
set  to  T,  so  that  proofs  are  printed  to  the  terminal.  By  setting 
PROVE. FILE  to  a disk  file  you  can  have  a proof  printed  to  a file  so  that 
It  can  be  Inspected  at  your  leisure. 

It  is  often  the  case  that  you  will  decide  the  theorem-p rover  Is 
falling  before  it  decides  that  It  is  failing.  If  you  decide  the  system 
Is  falling  you  should  abort  the  proof  by  typing  CTRL-E,  get  the  system 
to  prove  the  necessary  lemmas,  and  then  try  to  prove  the  "difficult" 
theorem  again.  Sote  that  it  is  permitted  to  abort  PROVE  with  CTRL-E  or 
CTRL-D  without  risking  messing  up  the  system's  state  because  PROVE  does 
not  change  the  state. 

You  may  abort  the  printing  of  any  formula,  without  aborting  the 
proof  attempt,  by  typing  CTRL-K. 

The  result  of  PROVE  is  either  the  INTERLISP  literal  atom  PROVED  or 
a very  large  failure  message  string.  When  the  failure  message  string  Is 
returned,  the  most  you  are  entitled  to  conclude  Is  that  the  system  was 
Incapable  of  finding  a proof.  In  particular,  the  failure  message  does 
not  mean  that  the  formula  Is  not  a theorem.  It  Is  often  the  case  that 
the  failure  message  Is  precipitated  by  the  system's  discovery  that  It  Is 
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trying  to  prove  a goal  that  Is  falslflable<  However,  even  In  this  case 
you  may  not  conclude  that  the  Input  conjecture  was  a nontheorem  since 
during  the  proof  attempt  the  system  might  have  abandoned  the  original 
formula  In  favor  of  a mechanically  generated  generalization  (that  might 
not  In  fact  be  a theorem) . 

AG.  PROVE. FILE 

The  value  of  the  variable  PROVE. FILE  should  be  the  name  of  an  open 
file  to  which  you  want  proofs  to  be  written.  Both  DEFN  and  PROVE .LEMMA 
direct  their  output  to  PROVE. FILE.  Initially  PROVE. FILE  Is  set  to  T 
(the  terminal).  If  PROVE. FILE  Is  set  to  a name  other  than  T when  DEFN 
or  PROVE. LEMMA  or  REDO. UNDONE. EVE NTS  Is  called  and  the  file  named  Is 
closed,  the  system  sets  PROVE. FILE  to  T.  For  example  a typical  scenario 
Is  to  set  PROVE. FILE  to  the  name  of  a just  opened  file,  call  PROVE. LEMMA 
to  prove  a theorem  and  write  the  proof  to  the  disk,  and  then  call 
CLOSEALL  or  (CLOSEF  PROVE. FILE)  to  close  the  disk  file.  The  next  time 
you  call  one  of  the  functions  that  writes  to  PROVE. FILE  It  will  reset  It 
to  the  terminal. 

AH.  PROVE .LEMMA (name  lemma. types  term) 

PROVE. LEMMA  attempts  to  prove  the  conjecture  term  and  remember  It 
as  a lemma  named  name,  available  for  use  In  the  ways  specified  by  the 
list  of  lemma  types  In  lemma. types . PROVE. LEMMA  first  checks  to  see 
whether  term  Is  acceptable  as  a lemma  of  the  types  listed  (so  that  such 
an  error  can  be  reported  before  the  system  has  spent  the  time  necessary 
to  prove  term).  Provided  term  Is  acceptable  as  a lemma  of  the  types  In 
lemma. types.  PROVE .LEMMA  calls  PROVE  on  term.  If  the  result  Is  PROVED, 
PROVE. LEMMA  creates  a new  event  named  name,  associates  the  formula  term 
with  name,  and  makes  It  available  as  a lemma  to  be  used  In  the  ways 
specified  by  lemma. types.  The  event  Is  made  dependent  upon  all  of  the 
events  used  In  the  proof  of  term. 

Note  that  even  though  PROVE  can  be  aborted  safely  with  CTRL-E  or 
CTRL-D,  PROVE. LQIMA  cannot.  The  reason  Is  that  after  calling  PROVE  to 
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prove  the  formula,  PROVE .LEMMA  updates  the  state.  It  is  possible 
(though  extremely  unlikely)  that  you  would  decide  that  the  proof  Is 
falling  and  abort  when  in  fact  It  had  already  proved  the  theorem  and  was 
beginning  to  update  the  state  while  your  terminal  was  still  printing  out 
the  formulas.  The  only  approved  way  to  abort  PROVE. LEMMA  is  to  type 
CTRL-H  and  wait  for  a soft  INTERLISP  interrupt,  use  BT  in  the  resulting 
break  to  make  sure  that  the  system  is  still  under  the  call  to  PROVE,  and 
if  so  to  type  STOP  or  CTRL-D  to  abort  (and  if  not,  type  OK  to  continue 
the  final  stages  of  the  updating). 

AI.  PROVEALL (event .x^t  detach. fig  filename  sysoutf Ig) 


PROVEALL  is  a convenient  way  to  process  a command  sequence  and 
write  the  theorem-prover  output  to  a file.  PROVEALL  executes 
(REDO. UNDONE. EVENTS  event .1st  T 'A  detach. fig) 

, after  obtaining  30000  free  words  of  list  space,  setting  the  GC  message 

' • to  (which  will  be  changed  to  the  empty  string  if  the  job  is  to  be 

detached),  setting  PROVE. FILE  to  filename. PROOFS  and  TTY:  to 

/ 

file. name. TTY: . After  the  sequence  of  commands  has  been  processed, 
j PROVEALL  closes  both  PROVE. FILE  and  TTY:  and,  if  sysoutf Ig  is  non-NIL, 

r , makes  a SYSOUT  file  (called  filename.EXE). 

►'  Thus,  if  you  have  a sequence  of  events,  event  .1st,  to  be  executed 

and  you  wish  to  watch  the  progress  of  the  job  from  your  terminal,  but 
• have  the  proofs  go  to  the  file  DEMO. PROOFS,  you  would  execute  (PROVEALL 

j event. 1st  NIL  'DEMO).  During  the  proofs  your  terminal  would  display 

only  the  successive  event  names  as  they  were  encountered  during  the 
processing,  separated  by  commas,  and  Interspersed  with  dots  indicating 

the  GCs.  If  you  wished  to  have  the  events  executed  in  a detached  job 

I 

and  have  a SYSOUT  file  produced  afterwards  so  you  could  poke  around  if 
you  wished  (e.g. , to  produce  a library  file),  you  should  execute 
(PROVEALL  event. Is t T 'DEM)  T).  After  seeing  the  detach  message,  you 
could  then  turn  off  your  terminal  and  walk  away  while  the  system 
proceeded  to  do  the  proofs.  You  can  re-attach  your  job  at  any  time  by 
typing: 

@ATT  user  password  jobno 
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to  the  TOPS-20  EXEC,  where  user  is  your  user  name,  password  is  your 
password,  and  jobno  is  the  number  of  the  job  running  the  theorem-p rover . 
If  you  re-attach  while  the  PROVEALL  is  still  running,  it  will  resume 
printing  out  the  successive  event  names  separated  by  commas  (but  the 
garbage  collect  message  will  be  the  empty  string).  If  you  re-attach 
after  the  PROVEALL  has  terminated,  INTERLISP  will  print  the  value  of  the 
call  to  PROVEALL  and  you  may  proceed  as  usual.  It  is  good  practice 
after  a detached  PROVEALL  to  inspect  the  value  of  the  variable 
FAILED. THMS  to  see  if  any  proof  failed.  It  is  also  good  to  remember 
that  no  library  file  is  made  by  PROVEALL;  if  you  want  to  save  the 
system's  state  you  should  do  so  after  re-attaching. 


See  REDO. UNDONE. EVENTS  for  the  details  of  the  system's  behavior 
during  and  after  a detached  run. 


PUBLISH(flle  title] 


The  file  argument  is  assumed  to  be  the  name  of  a PROVE. FILE  written 
to  the  disk  by  PROVEALL  (or,  actually,  by  REDO. UNDONE. EVENTS  when  the 
two  final  flag  arguments  are  both  NIL).  That  is,  the  file  should 
consist  of  the  header  as  printed  by  REDO. UNDONE. EVENTS  followed  by  a 
sequence  of  commands,  theorera-prover  output,  and  values,  separated  by 
formfeeds.  PUBLISH  opens  file  for  reading;  creates  a new  version  for 
writing;  and  then  writes  in  sequence  a title  page  (with  title  centered 
on  it  above  the  system  identification  header  printed  by 
REDO. UNDONE. EVENTS) , a table  of  contents  listing  each  event  name  and  the 
page  on  which  it  became  defined,  each  command  and  its  output  and  value, 
a cross-referenced  index  (listing,  for  each  name  mentioned  in  the  file, 
every  page  on  which  the  name  appears),  and  the  summation  of  the  time  and 
CONS  usage  statistics  for  the  events.  PUBLISH  then  closes  both  files. 


If  you  list  the  created  file  with  the  TOPS-20  LIST  command  the  page 
numbers  printed  will  agree  with  with  those  in  the  table  of  contents  and 
index.  Events  requiring  several  physical  pages  of  output  are  LISTed 
with  page  numbers  such  as  7,  7:1,  7:2,  7:3,  ... 
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AK.  REDOl (name) 


REDO!  uses  UNDO. NAME  to  undo  the  event  named  name  and  then  uses 
REDO. UNDONE. EVENTS  to  reprocess  each  of  the  events  returned.  It  is 
mainly  used  to  cause  the  system  to  go  through  a proof  that  just  flashed 
by  on  the  screen  or  that  you  have  decided  to  repeat  for  demonstration  or 
documentation  purposes  (e.g. , between  the  first  proof  and  the  REDOl  you 
might  have  set  PROVE. FILE  to  be  a disk  file  so  you  could  capture  the 
proof) . 

AL.  REDO. UNDONE. EVENTS (events  all. fig  failure. act ion  detach. fig) 

REDO. UNDONE. EVENTS  is  used  to  process  a list  of  theorem-prover 
commands.  The  arguments  allow  you  to  select,  interactively,  the 
commands  to  be  executed,  to  specify  the  action  to  be  taken  should  a 
command  fall,  to  have  your  job  detached  while  the  commands  are  being 
executed,  and  to  control  the  printing  of  certain  header  information. 

The  list  events  is  assumed  to  be  a list  of  events  as  returned  by 
UNDO. NAME.  That  is,  each  element  of  events  is  a form  whose  CAR  is  one 
of  the  atoms  BOOT. STRAP,  ADD.AXICM,  ADD. SHELL,  DCL,  DEFN,  PROVE. LEMMA  or 
MOVE. LEMMA,  and  whose  CDR  is  an  appropriate  list  of  arguments. 

REDO. UNDONE. EVE NTS  applies  the  CAR  of  each  event  to  the  CDR.  There  are 
three  typical  sources  of  commands  for  REDO. UNDONE. EVENTS.  The  first  is 
the  list  of  events  returned  by  UNDO. NAME.  For  example,  if  after 
escaping  from  several  blind  alleys  you  have  finally  gotten  the  system  to 
prove  your  "main  theorem,"  you  might  undo  and  redo  a sequence  of  events 
to  write  the  entire  sequence  of  proofs  to  a file  for  documentation 
purposes.  Because  of  the  uncertainty  surrounding  the  validity  of  the 
theorem-p rover's  state  after  aborted  commands  and  the  doubts  about  the 
correctness  of  UNDO. NAME,  we  recommend  such  a final  uninterrupted 
"proveall"  as  the  only  sure  evidence  that  your  formulas  are  theorems. 

The  second  typical  source  of  input  for  REDO. UNDONE. EVENTS  is  a list 
of  events  on  a disk  file,  written  during  a previous  session  (the  result 
of  printing  the  value  of  EVENTS. SINCE,  perhaps). 


The  third  typical  source  of  events  is  a mechanical  conjecture 
generator,  such  as  a verification  condition  generator.  We  find  it 
convenient  for  our  vcg  programs  to  produce  a sequence  of  axioms, 
definitions,  declarations  and  conjectures  to  prove,  and  then  to  use 
REDO. UNDONE. EVE NTS  to  drive  our  sweep  through  the  list. 

Before  the  first  command  is  executed,  REDO. UNDONE. EVENTS  prints  a 
header  indicating  the  date  and  the  versions  of  the  LISP  and  theorem- 
prover  files  in  use.*  This  information  is  printed  to  PROVE. FILE.  If 
PROVE. FILE  is  T,  the  header  is  two  lines  of  Information.  Otherwise,  it 
is  centered  on  a page  delimited  by  formfeeds. 

As  REDO. UNDONE. EVENTS  sweeps  through  the  list  of  events,  it 
indicates  which  event  is  being  processed.  To  the  file  named  by 
PROVE. FILE,  REDO. UNDONE. EVENTS  prints  a formfeed  followed  by  the  entire 
form  about  to  be  executed  . After  each  command  is  executed, 

REDO. UNDONE. EVENTS  prints  the  value  of  the  event  to  PROVE. FILE.  Thus, 
PROVE. FILE  will  contain  each  command,  the  theorera-prover's  output  in 
response  to  the  command,  and  the  value  returned  by  the  command,  with 
formfeeds  separating  the  commands.  The  command  PUBLISH  can  be  used  to 
process  such  a file  to  add  a title  page,  table  of  contents,  and  cross- 
referenced  index. 

If  PROVE. FILE  is  not  the  terminal,  but  you  are  attached  to  the  job, 
then  it  is  useful  to  get  some  indication  as  to  how  the  job  is 
progressing.  In  this  case,  REDO. UNDONE. EVENTS  prints  to  the  terminal 
the  name  of  each  event  (i.e.,  the  CADR  of  the  form)  before  the  command 
is  processed  and  a comma  after  each  event  is  processed.  Thus,  if  you 


REDO. UNDONE. EVE NTS  actually  has  two  additional  arguments.  The  sixth 
argument  of  REDO. UNDONE. EVENTS  is  don't .print .date .line .fig;  if  it  is  T, 
the  printing  of  the  header  will  be  omitted. 

**  The  fifth  argument  of  REDO . UNDONE . EVENTS  is 

don't .print. first. event. fig;  if  it  is  T,  REDO. UNDONE. EVENTS  does  not 
print  the  first  command  on  events;  this  option  is  used  by  EDITEV  when  it 
calls  REDO. UNDONE. EVENTS  to  reprocess  an  edited  event  and  those  events 
depending  on  it.  In  this  case,  it  is  assumed  that  you  know  what  the 
edited  event  is  and  would  consider  it  an  inconvenience  to  see  the  result 
of  your  edit  printed  back  out  at  you. 


are  dumping  the  proofs  to  a file,  but  have  remained  attached  to  your 
job,  your  terminal  will  slowly  print  a sequence  of  event  names, 
separated  by  commas,  and  Interspersed  with  GC  messages. 

If  one  of  the  commands  In  events  causes  an  error,  the  usual  error 
message  will  be  printed  and  then  (provided  you  are  attached  to  the  job) 
you  will  be  put  Into  the  editor  editing  the  tall  of  events  starting  at 
the  offending  event.  Exiting  the  editor  with  STOP  or  CTRL-D  will  leave 
> DU  In  the  safe  state  the  system  was  In  before  It  encountered  the 
offending  command.  Exiting  the  editor  with  OK  will  cause  resumption  of 
the  command  processing  In  the  edited  tall.  The  tall  you  edit  Is 
physically  that  of  the  events  you  supply  REDO. UNDONE. EVENTS.  Thus,  when 
REDO. UNDONE. EVENTS  eventually  terminates,  the  list  of  events  supplied 
will  reflect  any  edits  you  performed  during  the  processing. 

The  tall  of  events  yet  to  be  processed  Is  kept  In  the  variable 
UNDONE. EVENTS.  If  you  abort  REDO. UNDONE. EVENTS  you  will  find  the  list 
of  events  that  have  not  been  redone  In  UNDONE. EVENTS.  However,  many  of 
the  theorem-p rover  commands  call  REDO. UNDONE. EVENTS  Internally  — In 
fact  all  of  the  event  creation  commands  such  as  DEFN  and  PROVE. LEMMA 
actually  call  REDO. UNDONE. EVE NTS  because  of  Its  error  handling.  Thus, 

If  after  an  aborted  call  to  REDO. UNDONE. EVE NTS  you  call  one  of  the 
standard  theorem' prove r commands  like  EDITEV  or  PROVE. LEMMA,  you  will 
find  that  UNDONE. EVENTS  has  been  reset  and  no  longer  contains  the  tall 
of  the  events  that  was  aborted.  You  should  therefore  save  UNDONE. EVENTS 
Immediately  after  REDO. UNDONE. EVENTS  has  been  aborted  If  you  wish  to 
save  It. 

Our  usual  protocol  for  getting  a sequence  of  commands  processed  Is 
to  set  XXX  to  the  sequence  and  call  REDO. UNDONE. EVENTS  on  XXX.  When  we 
see  a proof  fall  we  abort  REDO. UNDONE. EVENTS  and  call  EDITV  on 
UNDONE. EVENTS  to  either  correct  the  offending  event  or  precede  It  with 
what  we  believe  are  the  necessary  lemmas,  and  then  call  RESTART.  The 
advantage  of  this  technique  Is  that  when  we  finally  reach  the  end  of  the 
original  XXX  It  has  been  edited  along  the  way  to  contain  the 
unanticipated  lemmas  required. 
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The  second  argument  to  REDO. UNDONE. EVENTS,  all. fig,  determines 
whether  all  or  only  some  of  the  events  In  events  are  redone.  If  all. fig 
is  NIL,  then  when  REDO. UNDONE. EVENTS  encounters  a non-DEFN  event  in 
events  it  asks  you  whether  you  wish  to  redo  that  event,  if  all. fig  is 
non-NIL,  all  events  are  redone.  The  all. fig  option  of 
REDO. UNDONE. EVE NTS  is  used  by  EDITEV  so  that  when  you  reconstruct  the 
sequence  of  events  depending  on  an  undone,  edited  definition,  the 
functions  that  call  the  edited  function  as  a "subroutine"  are 
automatically  reprocessed  and  you  have  the  freedom  to  specify  which 
dependent  lemmas  the  system  should  try  to  prove  again. 

The  third  argument,  failure. act  ion,  is  used  to  specify  the  system's 
action  should  it  fall  to  prove  some  lemma  in  the  sequence  of  events. 

The  failure  to  prove  a lemma  deserves  special  attention  because  it  may 
be  impossible  for  the  system  to  prove  the  succeeding  lemmas  if  it  does 
not  have  the  failed  lemma  built  in.  If  failure. act ion  is  the  literal 
atom  Q (for  "Quit"),  a failed  proof  causes  REDO. UNDONE. EVENT  to  abort. 

If  failure. action  is  the  atom  C (for  "Continue")  a failed  proof  is 
Ignored,  in  the  sense  that  the  rest  of  the  events  on  events  are 
attempted  as  though  nothing  unusual  had  occurred.  If  failure. act  ion  is 
the  atom  A (for  "ADD. AXIOM"),  the  lemma  is  added  as  an  axiom  so  that 
subsequent  proofs  will  not  fall  because  of  the  absence  of  the  single 
lemma  the  system  failed  to  re-establish.  If  failure. act ion  is  NIL,  then 
the  system  asks  you  (with  ASKUSER)  what  failure. action  should  be;  the 
response  "?"  typed  to  its  question  will  prompt  the  system  to  list  the 
alternatives  given  above. 

The  fourth  argument,  detach. fig,  if  T,  causes  the  system  to  detach 
your  job  and  then  start  processing  events . However,  the  job  will  hang 
if  it  ever  tries  to  do  input  or  output  to  the  terminal  while  detached. 
Thus,  before  running  in  detached  mode  the  theorem-p rover  should  be 
"rigged  for  silent  running."  In  particular,  PROVE. FILE  and  TTY:  must  be 
set  to  some  file  other  than  the  terminal,  and  the  INTERLISP  garbage 
collector  must  be  "gagged"  to  prevent  it  from  printing  its  usual  GC 
message.  Thus,  if  detach. fig  is  T,  REDO. UNDONE. EVENTS  gags  the  garbage 


1 

i' 

collector  and  checks  that  PROVE. FILE  and  TTY:  are  appropriately  set.  If  ’ 

they  are  not  appropriately  set.  It  asks  you  to  specify  the  desired  file 
names.  Once  the  system  has  been  rigged  for  silent  running, 

REDO. UNDONE. EVENTS  automatically  detaches  the  job  and  then  begins  to 
process  the  commands  as  described  above.  When  you  see  the  system  print 
the  message  that  your  job  has  been  detached,  you  are  free  to  turn  your 
terminal  off  and  walk  away. 

j|  To  enable  you  to  monitor  the  progress  of  your  detached  job, 

I REDO. UNDONE. EVENTS  changes  the  name  of  the  job  from  "LISP"  to  a name  of 

f the  form  "n/m",  where  n is  the  number  of  events  in  events  still  to  be 

! processed,  and  m Is  the  number  of  lemmas  that  the  system  has  failed  to 

prove.  The  job  name  is  updated  every  time  REDO. UNDONE. EVENTS  steps  to  a 
new  entry  in  events . When  the  last  event  has  been  processed,  the  job 
name  Is  changed  to  DONE. 

If  at  any  time  you  want  to  see  the  job  name,  connect  to  the 
operating  system  (not  necessarily  logging  in)  and  type: 

@8ys  user 

where  user  is  your  user  name  (or  else  the  number  of  the  job  running  the 
theorem-p rover) . 

You  can  re-attach  your  job  at  any  time  by  typing: 

@ATT  user  password  jobno 

to  the  TOPS-20  EXEC,  where  user  Is  your  user  name,  password  is  your 
password,  and  jobno  Is  the  number  of  the  job  running  the  theorem-prover. 

If  you  re-attach  while  REDO. UNDONE. EVENTS  is  still  running.  It  will 
resume  printing  out  the  successive  event  names  separated  by  commas  (but 
the  garbage  collections  will  be  silent).  If  you  re-attach  after 
REDO. UNDONE. EVENTS  has  terminated,  INTERLISP  will  print  the  value  of  the 
call  to  REDO. UNDONE. EVENTS  and  you  may  proceed  as  usual.  It  Is  good 
practice  after  re-attachlng  a detached  REDO. UNDONE. EVENTS  to  Inspect  the 
value  of  the  variable  FAILED. TmS  to  see  if  any  proofs  failed.  It  Is 
also  good  to  consider  whether  to  save  the  system's  state  after  the 
R EDO . UNDONE .EVENTS . 
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If  an  error  arises  during  a detached  run,  the  system  prints  the  I 

appropriate  message  to  the  TTY:  file,  changes  the  Job  name  to  ERROR,  and 
sleeps  until  the  job  Is  re-attached.  When  you  re-attach  the  job  you 
should  type  CTRL-E  (to  signal  to  the  sleeping  job  that  you  are  now  there 
to  field  the  error).  The  system  then  reprints  the  message  to  the 
terminal  and  enters  the  usual  Interactive  break.  (Sleeping  Is  subtly 
different  from  the  "hanging"  that  occurs  should  the  job  try  to  read  from 
or  write  to  the  terminal;  a job  that  Is  so  hung  Is  automatically  logged 
out  by  the  system  after  a certain  grace  period.  The  sleep  Induced  by  an 
error  permits  the  job  to  avoid  the  Inactive  job  reaper  Indefinitely.) 

It  Is  usually  the  case  that  when  the  system  crashes,  you  lose  all 
files  created  but  not  closed  before  the  crash.  This  happens  because  the 

i 

directory  entry  for  a file  being  written  Is  usually  not  updated  until  j 

the  file  Is  closed.  Since  It  Is  not  unusual  for  REDO. UNDONE. EVENTS  to  j 

run  for  a long  time  compared  to  the  mean  time  between  SRI-KL  crashes  I 

(e.g.,  reprocessing  all  of  the  events  In  our  PROVEALL.LIB  library  j 

requires  about  2 CPU  hours)  REDO. UNDONE. EVENTS  uses  JSYS  calls  to  update 

the  directory  entries  for  PROVE. FILE  and  TTY:  every  time  It  steps  to  the 

next  event.  Thus,  If  the  system  crashes  while  you  are  running  a 

detached  job,  you  will  lose  the  state  but  you  will  at  least  have  the 

system  output  up  to  the  proof  during  which  the  system  crashed. 

AM.  RESTART (x) 

(RESTART  X)  Is  just  (REDO. UNDONE. EVENTS  (OR  X UNDONE. EVENTS)  T 'Q). 

This  function  Is  a handy  way  to  continue  an  Interrupted 

REDO. UNDONE. EVENTS.  Recall  that  when  REDO. UNDONE. EVE NTS  terminates  the 

variable  UNDONE. EVENTS  Is  set  to  the  tall  of  the  event  list  still  to  be  ■ 

processed.  RESTART  just  calls  REDO. UNDONE. EVENTS  again,  giving  It 

UNDONE. EVENTS  as  the  event  list.  However,  note  that  UNDONE. EVENTS  Is 

liable  to  be  reset  by  any  command  that  creates  an  event  (e.g.,  DEFN  or 

PROVE.LEMMA) . 

Our  usual  protocol  for  using  REDO. UNDONE. EVENTS  and  RESTART  Is  to 
abort  REDO. UNDONE. EVENTS  when  we  see  a proof  fall,  to  call  EDITV  on 

J 
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UNDONE. EVENTS  to  either  correct  the  offending  event  or  precede  it  with 
what  we  believe  are  the  necessary  lemmas,  and  then  to  call  RESTART.  The 
advantage  of  this  technique  is  that  when  you  finally  reach  Che  end  of 
the  original  events  it  has  been  edited  along  the  way  to  contain  Che 
unanticipated  lemmas  required. 

AN.  REWRITE 

REWRITE  is  one  of  the  "lemma  types"  that  specifies  how  a lemma  may 
be  used.  Roughly  speaking,  REWRITE  lemmas  are  used  by  the  simplifier  to 
rewrite  terms  conditionally.  Let  the  lemma  in  question  be  term.  If 
term  is  of  the  form  (IMPLIES  hyp  concl),  concl  is  used  as  a rewrite  rule 
when  the  system  can  establish  hyp;  otherwise,  term  is  treated  as  though 
it  were  (IMPLIES  T term).  If  the  conclusion  is  (EQUAL  r s).  Instances 
of  r are  rewritten  to  s.  A conclusion  of  the  form  (NOT  r)  is  used  just 
as  though  it  were  (EQUAL  r F).  A conclusion  of  the  form  r,  where  Che 
function  symbol  is  neither  EQUAL,  NOT,  nor  LESSP  is  used  to  establish 
that  Instances  of  r are  non-FALSE.  See  ACL  VII  for  complete  details  of 
how  REWRITE  lemmas  are  used. 

We  have  recently  added  a linear  arithmetic  package  to  the 
simplifier.  This  package  causes  certain  lemmas  with  a conclusion  of  the 
form  (LESSP  a b)  or  (NOT  (LESSP  a b))  to  be  treated  specially.  Here  is 
the  restriction  on  a and  b.  Consider  a and  b as  PLUS-trees  (i.e. , trees 
of  non-PLUS  terms  connected  by  the  function  symbol  PLUS).  Then  at  least 
one  of  the  non-PLUS  tips  of  one  of  the  two  trees  must  be  a terra  that 
includes  every  variable  in  the  lemma.  Thus,  if  X and  Y are  the  only 
variables  in  a lemma  and  the  conclusion  is  (LESSP  X (TIMES  X Y)),  the 
lemma  meets  the  above  restriction.  A conclusion  of  (LESSP  (FN  X)  (FN 
Y))  or  (LESSP  X (PLUS  (FN  X)  (FN  Y)))  does  not  meet  the  restriction. 

This  restriction  is  present  because  such  "maximal  addends"  are  keyed  on 
by  the  linear  arithmetic  package  and  trigger  the  instantiation  of  the 
lemma  (Instantiating  all  its  variables)  and  the  addition  of  the  instance 
to  the  "pot"  of  linear  Inequalities  being  processed. 
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To  disable  the  linear  arithmetic  package  and  to  prevent  future 
REWRITE  lemmas  from  being  stored  in  it,  set  NO.BUILT.IN.ARITH.FLG  to  T. 
Note  that  this  will  not  suddenly  cause  previously  stored  linear  lemmas 
to  be  used  as  rewrite  rules.  To  get  a lemma  with  a LESS?  conclusion 
stored  and  used  as  a rewrite  rule  while  the  linear  package  is  still 
enabled  you  can  hide  the  LESS?  by  writing  the  conclusion  as  (EQUAL 
(LESS?  a b)  T)  or  (EQUAL  (LESS?  a b)  F)  as  appropriate. 

AO.  TRANSLATE (term) 

TRANSLATE  is  the  program  that  checks  for  syntax  errors  in  S- 
expressions  and  removes  the  abbreviations  permitted  in  our  theory.  For 
examp le, 

_TRANSLATE( (APPLY  (QUOTE  PUSHV)  2 (CADR  X))) 

returns  the  value 

(APPLY  (PACK  (ADDl  (ZERO))) 

(ADDl  (ADDl  (ZERO))) 

(CAR  (CDR  X))) 

(provided  (QUOTE  PUSHV)  is  the  abbreviation  for  the  literal  atom  (PACK 
1)).  TRANSLATE  causes  errors  when  it  finds  illegal  syntax  such  as  too 
few  arguments  or  unknown  function  symbols. 

All  of  the  event  creating  routines  in  our  system  (e.g.,  DEFN  and 
PROVE. LEMMA)  call  TRANSLATE  on  user-supplied  terms.  None  of  the 
internal  routines  in  the  system  know  about  abbreviations  (e.g.,  if  you 
type  in  a term  involving  99,  it  is  expanded  to  a nest  of  99  ADDl's). 

AP.  TTY; 

The  value  of  the  variable  TTY:  is  supposed  to  be  the  name  of  an 
open  file  to  which  error  and  warning  messages  are  printed.  Initially 
TTY:  is  set  to  T (the  terminal). 

Each  error  message  is  first  printed  to  PROVE. FILE.  Then,  if 
PROVE. FILE  and  TTY:  are  set  to  different  file  names,  the  error  message 
is  printed  to  TTY:  as  well.  Thus,  by  setting  PROVE. FILE  to  a disk  file 
and  TTY:  to  the  terminal  you  can  have  a coin)lete  record  of  the  system's 
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output  on  the  disk  and  have  error  messages  (also)  printed  to  your 
terminal*  By  setting  TTY:  and  PROVE. FILE  to  two  different  disk  files 
you  can  have  no  output  to  the  terminal  and  should  Inspect  TTY:  later  to 
see  whether  any  errors  occurred. 

AQ.  UNDO. BACK. THROUGH (name) 

This  command  "rolls  back"  the  theorem-prover's  scate  to  the  one 
that  existed  just  before  the  event  named  name  was  created.  It  works  by 
undoing.  In  reverse  chronological  order,  name  and  every  event  created 
after  name. 

AR.  UNDO. NAME (name) 

UNDO. NAME  removes  from  the  event  graph  every  event  reachable  from 
the  one  named  name.  (If  name  Is  a satellite.  Its  main  event  Is  used 
Instead.)  Roughly  speaking,  this  puts  you  Into  the  state  you  would  have 
bean  In  now  had  you  done  all  the  events  except  the  event  being  undone 
and  those  events  that  depend  upon  It.  UNDO. NAME  undoes  exactly  the 
events  listed  by  DEPENDENT. EVENTS,  so  you  can  use  DEPENDENT. EVENTS  to 
ascertain  the  amount  of  damage  that  would  be  caused  by  undoing  a given 
event.  UNDO.NAME  returns  exactly  the  same  list  that  DEPENDENT. EVENTS 
does;  such  a list  can  be  given  to  REDO. UNDONE. EVENTS  to  attempt  to 
reconstruct  the  undone  events. 

UNDO.NAME  Is  not  like  the  INTERLISP  undo  facility  In  several 
respects.  The  main  difference  Is  that  UNDO.NAME  Is  a quasl-loglcal  act: 
not  only  are  the  effects  of  the  named  event  erased  but  the  effects  of 
all  subsequent  events  that  depended  on  It  are  erased.  A second 
Important  difference  Is  that  after  an  UNDO.NAME  all  traces  of  the  undone 
events  are  con^lettly  wiped  out:  It  Is  not  possible  to  undo  an  UNDO.NAME 
(except  by  reprocessing  the  original  events,  e.g.,  rediscovering  the 
proofs  of  the  lemmas  killed). 

WARNING  --  We  believe,  but  have  not  yet  proved,  that 
UNDO.NAME  Is  Implemented  as  specified  above.  It  Is  difficult 
to  ascertain  all  of  the  events  that  are  logically  dependent 
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upon  a given  event  because,  for  efficiency  reasons,  the 
theorem-p rover  does  not  record  uses  of  rewrite  rules  stored  as 
type  prescriptions.  When  UNDO. NAME  traces  the  dependencies  of 
such  a rewrite  rule.  It  must  determine  which  events  might  have 
appealed  to  that  lemma.  We  believe  that  our  Inqjlementatlon  of 
DEPENDENT. EVENTS  Is  correct  In  the  sense  that  It  returns  a 
superset  of  the  logical  dependents  of  Its  argument;  however, 
we  have  not  yet  entirely  convinced  ourselves  that  the 
computation  Is  correct.  Therefore,  If  you  have  constructed  a 
sequence  of  definitions  and  proofs,  and  have  availed  yourself 
of  UNDO. NAME  to  undo  your  missteps  along  the  way,  you  should 
have  the  system  reproduce  the  final  sequence  of  events  (with 
REDOl,  REDO. UNDONE. EVENTS  or  PROVEALL)  without  any  UNDO.NAMEs. 

Until  we  prove  UNDO. NAME  satisfies  the  above  specifications, 
the  careful  user  must  consider  It  (and  the  commands  that 
depend  upon  It  such  as  EDITEV)  as  a mere  "programmer's 
assistant"  command,  rather  than  a "logician's  assistant" 
command. 

UNDO. NAME  Is  definlv  ily  correct  when  the  event  undone  Is  the  last 
event  created.  Thus,  undoing  all  of  the  events  back  through  a given 
one.  In  reverse  chronological  order.  Is  guaranteed  to  have  the  specified 
effect-.  The  fimctlon  UNDO. BACK. THROUGH  provides  such  a chronological 
undoing.  Note  however  the  difference  between  undoing  backwards  from  the 
fringe  reachable  from  a node  (which  Is  what  UNDO. NAME  does)  and  undoing 
all  events  since  a node  was  added  (which  is  what  UNDO. BACK. THROUGH 
does) . 
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IV  REPORTING  OF  DIFFICULTIES 


If  you  have  difficulties  getting  the  theorem-prover  to  prove  a 
theorem  and  you  wish  to  obtain  our  advice,  please  provide  Che  following 
information  to  help  us  reproduce  your  situation: 

* A description  of  how  you  INITed  the  theorem-prover,  in’ 
particular  which  library  file,  if  any  you  are  using. 

* A description  of  any  UNDO.NAMEs  or  EDITEVs  that  changed  the 
state  described  by  that  library  file. 

* A disk  file  containing  a list  of  the  event  producing 
commands  that  you  have  executed  after  the  INIT.  Such  a 
list  can  be  obtained  by  calling  EVENTS. SINCE  on  the  name  of 
the  first  event  created  after  the  INIT. 

* An  informal  sketch  of  why  your  conjecture  is  a theorem 
(e.g.,  "This  conjecture  follows  immediately  from  the 
previously  proved  REWRITE  rules  foo  & bar.") 
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V EXTREMELY  SIMPLE  EXAMPLES 


The  first  time  you  use  a new  computing  system  Is  usually  painful. 
One  reason  for  this  difficulty  Is  the  arbitrariness  of  the  syntax  of 
most  operating  system  command  languages,  which  are  among  the  most  poorly 
designed  of  computer  programming  languages.  TOPS-20  Is  no  exception. 
Another  reason  Is  that  even  the  simplest  use  of  a system  may  require 
saving  and  retrieving  Information  from  a permanent  storage  facility  such 
as  a disk  file;  but  10  Is  the  most  complex  aspect  of  any  computing 
language.  To  help  you  get  started,  we  present  four  extremely  simple 
example  sessions  with  the  theorem-prover. 

We  underline  those  characters  that  are  typed  by  the  user.  We 
demark  comments  lines  that  are  not  part  of  the  session  by  beginning  the 
lines  with  semicolons.  To  Increase  legibility,  we  have  added  some  blank 
lines.  Some  user-typed  carriage  returns  that  may  not  be  obvious  are 
written  "<cr>". 

A.  Example  ^ 

SRI-KL,  TOPS-20  Monitor  1018(120) 

System  shutdown  scheduled  for  Wed  ll-Apr-79  23:00:00, 

Up  again  at  Thu  12-Apr-79  04:00:00 

There  are  17+10  jobs  and  the  load  av.  Is  0.80 

gLOG  USERNAME(unechoed  password )ACCOUNT<cr> 

Job  18  on  TTY250  9-Apr-79  07:21 
Previous  login:  9-Apr-79  06:42  from  TTY131 

gPEF  DSK:  DSK; . <MOORE><cr> 
gTHM<cr> 

(<MOORE>THM.EXE.l  . <LISP>LISP.EXE. 128) 
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*** 


2>^INIT(T) 

compiled  on  7-Apr-79  22:54:15 
FILE  CREATED  7-Apr-79  22:54:12 
CODEICOMS 

FILE  CREATED  7-Apr--79  18:09:07 
DATAICOMS 

compiled  on  7-Apr-79  17:56:06 
(GROUND. ZERO) 


3 JEFN (APPEND  (X  Y 


ISTP  Y)  (CONS  (CAR)  (APPEND 


ERROR:  CAR  is  a reserved  abbreviation  for  a CAR/CDR  nest  and 
must  be  given  exactly  one  argument. 


l*PP<cr> 

;We  are  thrown  into  the  INTERLISP  Editor.  The  command  lines 
:cc^taining  the  asterisk  prompt  character  are  editor  commands. 

(DEFN  APPEND  (X  Y) 

(IF  (LISTP  Y) 

(CONS  (CAR) 

(APPEND  (CDR  X) 

Y)) 

Y) 

NIL) 


;We  replace  "(CAR)"  with  "(CAR  X)". 

2*0K<cr> 

;And  proceed. 

WARNING:  The  admissibility  of  APPEND  has  not  been 
established.  We  will  assume  the  function  to  be 
well-defined.  This  may  render  the  theory  Inconsistent.  An 
induction  principle  for  this  function  has  been  assumed, 
corresponding  to  the  obvious  subgoal  induction  for  the 
function. 

Observe  that  (OR  (LISTP  (APPEND  X Y))  (EQUAL  (APPEND  X Y) 
Y))  is  a theorem. 


***  F A I L E D I *** 
***  *** 
A ****** A****** ********* A************ A******** A A**************** A*** 


4.-EDITEV  (APPEND) 


tty: 


3*PP 


(DEFN  APPEND  (X  Y) 

(IF  (LISTP  Y) 

(CONS  (CAR  X) 

(APPEND  (CDR  X) 
Y)) 

Y)) 


;We  should  have  made  sure  X was  a LISTP  before  CDRlng  it 
;ln  recursion.  Instead,  we  checked  Y. 


Load  average  during  proof:  1.097168 
Elapsed  time:  7.162  seconds 

CPU  time  (devoted  to  theorem  proving):  1.016  seconds 
GC  time:  .322  seconds 
10  time:  0.0  seconds 
CONSes  consumed:  855 


****************************************************** ************* 


*** 

*** 

*** 

FAILED! 

*** 

*** 

*** 

") 


Load  average  during  definition:  1.074789 
Elapsed  time:  4.271  seconds 

CPU  time  (devoted  to  theorem  proving):  .665  seconds 


4*0K 


The  lemma  CDR.LESSP  establishes  that  (COUNT  X) 
decreases  according  to  the  well-founded  function  LESSP  in 
each  recursive  call.  Hence,  APPEND  is  accepted  under  the 
definitional  principle.  Observe  that: 

(OR  (LISTP  (APPEND  X Y)  ) 

(EQUAL  (APPEND  X Y)  Y) ) 
is  a theorem. 
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GC  time:  >348  seconds 
10  time:  0.0  seconds 
CONSes  consumed:  504 

APPEND 

5J)EFN(PLISTP  (X 


ISTP  X)  (PLISTP  (CDR  X))  (EQUAL  X NIL 


The  lemma  CDR.LESSP  can  be  used  to  establish  that 
(COUNT  X)  decreases  according  to  the  well-founded  function 
LESSP  In  each  recursive  call.  Hence,  PLISTP  Is  accepted 
under  the  definitional  principle.  Observe  that: 

(OR  (FALSER  (PLISTP  X)) 

(TRUER  (PLISTP  X))) 

Is  a theorem. 

Load  average  during  definition:  1.046235 
Elapsed  time:  2.998  seconds 

CPU  time  (devoted  to  theorem  proving):  .579  seconds 
GC  time:  .342  seconds 
10  time:  0.0  seconds 
CONSes  consumed:  435 

PLISTP 

6uDEFN(REVERSE  (X)  (IF  aiSTP  X)  (APPEND  (REVERSE  (CDR  X 


NIL 


The  lemma  CDR.LESSP  establishes  that  (COUNT  X) 
decreases  according  to  the  well-founded  function  LESSP  In 
each  recursive  call.  Hence,  REVERSE  Is  accepted  under  the 
definitional  principle.  Observe  that: 

(OR  (LITATOM  (REVERSE  X)) 

(LISTP  (REVERSE  X))) 

Is  a theorem. 

Load  average  during  definition:  1.022781 
Elapsed  time:  5.0  seconds 

CPU  time  (devoted  to  theorem  proving):  .777  seconds 
GC  time:  .316  seconds 
10  time:  0.0  seconds 
CONSes  consumed:  538 

REVERSE 

7^ PPE (APPEND  PLISTP  REVERSE) 
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(DEFN  APPEND 
(X  Y) 

(IF  (LISTP  X) 

(CONS  (CAR  X)  (APPEND  (CDR  X)  Y) ) 

Y)) 

(DEFN  PLISTP 
(X) 

(IF  (LISTP  X) 

(PLISTP  (CDR  X)) 

(EQUAL  X NIL) ) ) 

(DEFN  REVERSE 
(X) 

(IF  (LISTP  X) 

(APPEND  (REVERSE  (CDR  X) ) 

(CONS  (CAR  X)  NIL)) 

NIL)) 

NIL 

8_PROVE.LEMMA(REVERSE. REVERSE  (REWRITE)  (IMPLIES  (PLISTP  X) 
(EQUAL  (RFVERSE  (REVERSE  X))  X] 

Name  the  conjecture  *1. 


Let  us  appeal  to  the  Induction  principle. 

;We  omit  the  meat  of  the  proof. 

That  finishes  the  proof  of  *1.1,  which,  consequently, 
finishes  the  proof  of  *1.  Q.E.D. 

Load  average  during  proof;  1.165718 
Elapsed  time:  58.373  seconds 

CPU  time  (devoted  to  theorem  proving);  6.372  seconds 
GC  time;  4.403  seconds 
10  time;  2.571  seconds 
CONSes  consumed;  7781 


PROVED 

9^(SET0  FOO  (EVENTS. SINCE  ^APPEND)) 

((DEFN  APPEND  (X  Y)  (IF  (LISTP  X)  (CONS  (CAR  X)  (APPEND  (CDR 
X)  Y))  Y))  (DEFN  PLISTP  (X)  (IF  (LISTP  X)  (PLISTP  (CDR  X)) 
(EQUAL  X NIL)))  (DEFN  REVERSE  (X)  (IF  (LISTP  X)  (APPEND 
(REVERSE  (CDR  X))  (CONS  (CAR  X)  NIL))  NIL))  (PROVE .LEMMA 
REVERSE. REVERSE  (REWRITE)  (IMPLIES  (PLISTP  X)  (EQUAL 
(REVERSE  (REVERSE  X))  X)))) 
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;Here  is  a very  slople  procedure  for  saving  FOO  on  a TOPS-20 
;dlsk  file. 


10.  (SETQ  REVCOMS  ^((VARS  FOO))) 

((VARS  FOO)) 

11  MAKEFILE (REV) 

<USERNAME>REV. . 1 

2C 

gPIR  REV<cr> 

;We  note  that  the  file  REV. .1  has  been  created. 

<USERNAME> 

REV..1 

;Just  to  make  sure,  we  now  type  the  file  on  the  terminal. 
giYPE  REV..l<cr> 

(FILECREATED  " 9-Apr-79  06:52:29"  <USERNAME>REV. .1  648 
changes  to;  REVCOMS  FOO) 


(PRETTYCOMPRINT  REVCOMS) 

(RPAQQ  REVCOMS  ((VARS  FOO))) 

(RPAQQ  FOO  ( (DEFN  APPEND  (X  Y) 

(IF  (LISTP  X) 

(CONS  (CAR  X) 

(APPEND  (CDR  X) 

Y)) 

Y)) 

(DEFN  PLISTP  (X) 

(IF  (LISTP  X) 

(PLISTP  (CDR  X) ) 

(EQUAL  X NIL))) 

(DEFN  REVERSE  (X) 

(IF  (LISTP  X) 

(APPEND  (REVERSE  (CDR  X)) 

' (CONS  TCAR  H) 

NIL) ) ^ 

NIL)) 

(PROVE. LEMMA  REVERSE. REVERSE  (REWRITE) 

(IMPLIES  (PLISTP  X) 

(EQUAL  (REVERSE  (REVERSE  X) ) 


■ fit] 


I 


» 

I 

i 


DECLARE:  DONTCOPY 
(FILEMAP  (NIL))) 
STOP 


X))))) 


B . Example  2^ 

Having  created  the  disk  file  REV..1,  we  can  redo  the  list  of  events 


thus  saved  in  another  theorem  proving  session. 


grHM<cr> 

(<M00RE>THM.EXE.1  . <LISP>LISP. EXE . 126) 


2 JNIT(T) 

complied  on  7-Apr-79  22:54: 15 
FILE  CREATED  7-Apr-79  22:54:12 
CODEICOMS 

FILE  CREATED  7-Apr-79  18:09:07 
DATAICOMS 

compiled  on  7-Apr-79  17:56:06 
(GROUND. ZERO) 

3>1.0AD(REV) 

FILE  CREATED  9-Apr-79  06:52:29 
REVCOMS 

<USERNAME>REV. . 1 


4 JP(FOO) 

((DEFN  APPEND  (X  Y) 

(IF  (LIST?  X) 

(CONS  (CAR  X) 

(APPEND  (CDR  X) 

Y)) 

Y)) 

(DEFN  PLISTP  (X) 

(IF  (LISTP  X) 

(PLISTP  (CDR  X)) 

(EQUAL  X NIL))) 

(DEFN  REVERSE  (X) 

(IF  (LISTP  X) 

(APPEND  (REVERSE  (CDR  X)) 
(CONS  (CAR  X) 

NIL)) 

NIL)) 

(PROVE. LEMMA  REVERSE. REVERSE  (REWRITE) 
(IMPLIES  (PLISTP  X) 
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(EQUAL  (REVERSE  (REVERSE  X)) 

X)))) 

(FOO) 

:Here  Is  a method  for  getting  proofs  printed  to  a file. 
5.,(SETQ  PROVE. FILE  (OUTPUT  (OUTFILE  "REV.PROOFSl 
(PROVE. FILE  reset) 

<USERNAME>REV. PROOFS. 1 
6.-(R  EDO.  UNDONE.  EVE  NTS  FOO) 

What  should  be  done  If  a proof  falls?  ?<cr> 

one  of: 

Quit 

Continue 
Add  as  axiom 

What  should  be  done  If  a proof  falls?  Qult<cr> 

APPEND .PLISTP, REVERSE, REVERSE .REVERSE 

Do  you  want  to  redo  this  event?  Yes<cr> 

.(APPEND  PLISTP  REVERSE  PROVED) 

7^(CL0SEF  PROVE. FILE) 

<USERNAME>REV.  PROOFS. 1 

IC 

;The  file  REV. PROOFS. 1 now  contains  all  of  the  theorem-prover 
;output  In  response  to  the  event  list  FOO.  Here  Is  what 
;the  file  looks  like: 

gTYPE  REV. PROOFS. l<cr> 

<LISP>LISP.EXE.128 
<M00RE>C0DE..3 
<MOOREX:ODEl . .4 
<MOORE>DATA. . 3 
<MOORE>DATA1..3 
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Monday,  April  9,  1979  6 ; 5 SAM-PST'T. 


_DEFN(APPEND  (X  Y) 

(IF  (LISTP  X) 

(CONS  (CAR  X)  (APPEND  (CDR  X)  Y) ) 

Y)) 

The  lemma  CDR >1 ESS P establishes  that  (COUNT  X) 
decreases  according  to  the  well-founded  function  LESSP  In 
each  recursive  call*  Hence,  APPEND  Is  accepted  under  the 
definitional  principle.  Note  that: 

(OR  (LISTP  (APPEND  X Y) ) 

(EQUAL  (APPEND  X Y)  Y)) 

is  a theorem. 

Load  average  during  definition:  1.478143 
Elapsed  time:  4.332  seconds 

CPU  time  (devoted  to  theorem  proving):  .781  seconds 
GC  time:  .254  seconds 
10  time:  0.0  seconds 
CONSes  consumed:  615 


APPEND 

~L 

_DEFN(PLISTP  (X) 

(IF  (LISTP  X) 

(PLISTP  (CDR  X) ) 

(EQUAL  X NIL) ) ) 

The  lemma  CDR. LESSP  informs  us  that  (COUNT  X)  goes  down 
according  to  the  well-founded  function  LESSP  in  each 
recursive  call.  Hence,  PLISTP  is  accepted  under  the 
definitional  principle.  Observe  that: 

(OR  (FALSER  (PLISTP  X)) 

(TRUER  (PLISTP  X))) 

Is  a theorem. 

Load  average  during  definition:  1.478143 
Elapsed  time:  1.109  seconds 

CPU  time  (devoted  to  theorem  proving):  .541  seconds 
GC  time:  .175  seconds 
10  time:  0.0  seconds 
CONSes  consumed:  436 
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rik) 


PLISTP 

a 

_DEFN(REVERSE  (X) 

(IF  (LISTP  X) 

(APPEND  (REVERSE  (CDR  X)) 

(CONS  (CAR  X)  NIL)) 

NIL)) 

The  lemma  CDR.LESSP  establishes  that  (COUNT  X)  goes 
down  according  to  the  well-founded  function  LESSP  in  each 
recursive  call*  Hence,  REVERSE  is  accepted  under  the 
principle  of  definition.  Observe  that; 

(OR  (LITATOM  (REVERSE  X)) 

(LISTP  (REVERSE  X))) 

is  a theorem. 

Load  average  during  definition:  1.478143 
Elapsed  time:  .999  seconds 

CPU  time  (devoted  to  theorem  proving);  .607  seconds 
GC  time:  .178  seconds 
10  time:  0.0  seconds 
CONSes  consumed:  538 

REVERSE 

~L 

_PROVE.LEMMA(REVERSE. REVERSE  (REWRITE) 

(IMPLIES  (PLISTP  X) 

(EQUAL  (REVERSE  (REVERSE  X))  X))) 


Name  the  conjecture  *1. 

We  will  try  to  prove  it  by  induction. 

:We  again  omit  most  of  the  proof. 

That  finishes  the  proof  of  *1.1,  which,  consequently, 
also  finishes  the  proof  of  *1.  Q.E.D. 

Load  average  during  proof:  1.503348 
Elapsed  time:  22.516  seconds 

CPU  time  (devoted  to  theorem  proving):  6.309  seconds 
GC  time:  3.032  seconds 
10  time:  2.49  seconds 
CONSes  consumed:  7781 

PROVED 
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C . Example  3_ 

Suppose  that  In  Example  1,  Immediately  after  the  proof  of  the 
REVERSE. REVERSE  theorem,  we  had  typed 

9.-MAKE.LIB  (REV.  LIB) 

and  the  system  returned 

<USERNAME>REV.LIB . 1 

Then  the  entire  state  of  the  theorem-prover  would  have  been  written  to 
the  new  file  <USERNAME>REV.LIB . 1.  Using  that  file  we  could  start 
another  session  from  that  state,  without  having  to  reprocess  the 
definitions  of  APPEND,  PLISTP  or  REVERSE,  or  prove  REVERSE. REVERSE 
again: 


grHM<cr> 

(<MOORE>THM.EXE.l  . <LISP>LISP.EXE. 128) 

2^NIT(REV.LIB) 

REVERSE. RE VERSE 

3^PE (APPEND  REVERSE. REVERSE) 

(DEFN  APPEND 
(X  Y) 

(IF  (LISTP  X) 

(CONS  (CAR  X)  (APPEND  (CDR  X)  Y) ) 

Y)) 

(PROVE.LEMMA  REVERSE. REVERSE  (REWRITE) 

(IMPLIES  (PLISTP  X) 

(EQUAL  (REVERSE  (REVERSE  X) ) 
X))) 


;Note  that  APPEND  and  RE VERSE. RE VERSE  are  events  in  the 
;current  data  base.  So  are  PLISTP  and  REVERSE.  In  fact, 

;the  theorem-prover  is  in  the  same  state  it  was  Ln  right 
;after  we  proved  REVERSE. REVERSE  in  Example  1.  For  example, 
;lt  now  knows  that  (REVERSE  (REVERSE  X))  is  X when  (PLISTP  X) 
;is  true  and  it  will  use  it  as  a rewrite  rule. 


D . Ex  amp  le  4 


We  conclude  with  some  light  humor* 


4>J)EFN(PP  (X)  (PP  X)) 

WARNING;  The  admissibility  of  PP  has  not  been  established. 
We  will  assume  the  function  to  be  well-defined.  This  may 
render  the  theory  Inconsistent.  An  induction  principle  for 
this  function  has  been  assumed,  corresponding  to  the  obvious 
subgoal  Induction  for  the  function. 


Note  that  F is  a theorem. 

; Pretty  smart  the orem-p rover,  eh?  Do  you  see  a proof  of  F? 

*******  A4i*******4t*4t4c**4t  A A*  ********  A*  ***********  It*  ********** 

***  *** 

***  FAILED!  *** 

***  *** 

******************************************************************* 


Load  average  during  proof:  1.399432 

Elapsed  time:  4.016  seconds 

CPU  time  (devoted  to  theorem  proving): 

GC  time:  .315  seconds 

10  time:  0.0  seconds 

CONSes  consumed:  110 


.238  seconds 


********************************************* ********* ******** ***** 
***  *** 

***  FAILED!  *** 

***  *** 

*******************************t^  <********************************* 


;Here's  a hint. 

5_PR0VE.LEMMA(PP. NONSENSE  (REWRITE)  (IMPLIES  (NOT  (PP  XJ)  (PP  X] 


Name  the  conjecture  *1. 

We  will  try  to  prove  It  by  Induction.  Two  Inductions 
are  suggested  by  terms  In  the  conjecture.  However,  they 
merge  Into  one  likely  candidate  Induction.  We  will  Induct 
according  to  the  following  scheme  (AND).  This  scheme  Is 


I 


■I 


justified  by  the  assumption  that  PP  is  total*  This 
produces: 

(TRUE) . 

That  finishes  the  proof  of  *1.  Q.E.D. 

Load  average  during  proof:  2.536146 
Elapsed  time:  12.445  seconds 

CPU  time  (devoted  to  theorem  proving):  .571  seconds 
GC  time:  .576  seconds 
10  time:  0.0  seconds 
COHSes  consumed:  348 


PROVED 

(3L0G0UT 


System  shutdovm  scheduled  for  Wed  ll-Apr-79  23:00:00, 

Up  again  at  Thu  12-Apr-79  04:00:00 
Logout  Job  18,  User  USERNAME,  Account  ACCOUNT,  TTY  250,  at 
9-Apr-79  07:24:08  Used  0:0:5  in  0:2:50 


I 

K 
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